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EXECUTIVE  SUMMARY 


The  DRDC  CORA  Maritime  Command  Pacific  (MARPAC)  Operational  Research  Team  has  a 
requirement  to  develop  a  baseline  intelligence,  surveillance  and  reconnaissance  (ISR)  model  for 
coastal  surveillance.  The  model  needs  to  be  developed  in  the  System  Toolkit  (STK)  software 
package  version  10.0  (or  higher)  to  ensure  required  fidelity  and  reliability  of  the  model. 

The  objective  of  this  activity  was  to  develop  an  STK  model  that  would  incorporate  current  ISR 
capabilities  employed  by  the  Royal  Canadian  Navy  (RCN)  for  coastal  surveillance,  as  well  as  a 
set  of  most  likely  targets.  At  the  high  level,  creation  of  this  STK  model  followed  sound 
engineering  practices  by  having  design,  development  and  verification  phases.  A  conceptual 
model  was  designed,  which  consists  of  two  implementation-independent  views  of  the  problem 
space;  this  allowed  the  conceptual  model  to  be  re-used  in  any  potential  future  related  work. 

Due  to  limitations  beyond  control  of  the  contractor,  the  model  had  to  be  developed  in  the  free 
version  of  STK,  which  is  available  for  public  download  from  the  Analytical  Graphics  Inc.  website. 
This  limitation  imposed  several  constraints  against  the  full  requirement  set  established  by 
DRDC,  which  resulted  in  a  model  that  was  not  able  to  achieve  all  of  the  original  objectives. 
Nonetheless,  the  contractor  was  able  to  generate  the  majority  of  the  platform  objects  (aircraft, 
ships,  and  satellites),  as  well  as  provide  placeholders  for  more  sophisticated  sensor  objects 
once  the  enhanced  version  of  STK  could  be  acquired. 

The  procedures  used  to  generate  the  STK  objects  and  associated  routes  in  the  scenario  are 
described  in  detail.  Similarly,  the  procedures  followed  and  results  from  surveillance  related 
analysis  that  was  achievable  in  the  free  version  of  STK  are  provided.  The  constraints  and 
limitations  associated  with  the  free  version  of  STK  and  with  STK  in  general  are  itemized  as  a 
reference  for  any  follow-on  work. 

Notwithstanding  the  constraints  and  limitations  imposed  and  experienced  during  the  conduct  of 
this  work,  the  contractor  was  able  to  achieve  measurable  successes  that  will  form  a  firm 
foundation  for  any  activities  that  may  follow-on  from  this  task  in  context  of  the  larger  DRDC 
objectives. 
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1  INTRODUCTION 

This  document  is  the  Final  Report  developed  for  the  project  entitled  “Coastal  Surveillance 
Baseline  Model  Development”.  This  report  was  completed  by  CAE  Canada  under  Task  #185  for 
contract  #W771 4-083663/001  /SV  to  Defence  Research  Development  Canada  (DRDC)  Centre 
for  Operational  Research  and  Analysis  (CORA). 

1.1  Background 

The  DRDC  CORA  Maritime  Command  Pacific  (MARPAC)  Operational  Research  Team  has  a 
requirement  to  develop  a  baseline  intelligence,  surveillance  and  reconnaissance  (ISR)  model  for 
coastal  surveillance.  The  model  needs  to  be  developed  in  the  System  Toolkit  (STK)  software 
package  version  10.0  (or  higher)  to  ensure  required  fidelity  and  reliability  of  the  model. 

1.2  Objective 

The  objective  of  this  activity  was  to  develop  an  STK  model  that  would  incorporate  current  ISR 
capabilities  employed  by  the  Royal  Canadian  Navy  (RCN)  for  coastal  surveillance,  as  well  as  a 
set  of  most  likely  targets. 

1.3  Scope 

Sensors,  sensor  platforms,  and  targets  needed  to  be  created  as  STK  objects,  and  implemented 
in  a  scenario  relevant  for  the  West  Coast  surveillance  tasks  (provided  in  an  Annex  to  the  Task 
statement  of  work  (SOW)).  As  a  minimum: 

a)  The  model  needed  to  capture  the  full  three-dimensional  topography  of  the  Canadian  East 
and  West  Coasts; 

b)  The  platforms  and  sensors  needed  to  be  defined  separately.  They  were  to  be  provided  as  a 
library  of  STK  objects  that  can  be  re-used  in  other  models,  and  sensors  were  to  be 
associated  with  relevant  platforms  in  the  baseline  scenario  implementation; 

c)  The  model  was  to  incorporate  twelve  sensor  platforms  (as  a  mix  of  space,  air,  sea,  and 
ground-based),  and  relevant  sensors  as  outlined  in  the  SOW  Annex; 

d)  The  targets  were  to  be  ships  as  follows:  large  vessel  over  300  gross  tonnage  (GT)  with 
Automatic  Information  System  (AIS)  transmitter,  large  vessel  over  300GT  with  AIS  off,  four 
types  of  fishing  vessels  ranging  in  size  between  150ft  and  250ft,  each  with  and  without  AIS 
transmitter  (for  a  total  of  eight  vessels),  four  types  of  small  vessels  (pleasure  craft)  ranging 
in  length  from  50ft  to  100ft,  with  variable  speed  (including  speed  boats)  (small/fast, 
small/slow,  large/fast,  large/slow);  and, 

e)  The  model,  including  platform  and  sensor  characteristics  and  disposition,  was  to  be 
documented  in  a  report. 
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1.4  Outline 

This  document  contains  the  following  sections: 

a)  Section  1  -  Introduction:  a  brief  description  of  the  background,  objective  and  scope  of  this 
work. 

b)  Section  2  -  Design:  descriptions  of  the  activities  and  outcomes  associated  with  the 
conceptual  model  and  requirements  to  accomplish  the  objectives  of  this  work. 

c)  Section  3  -  Implementation:  descriptions  of  the  activities  and  outcomes  associated  with  the 
development  of  the  STK  model  required  under  this  work,  including  limitations  and  model  use 
of  simple  analysis. 

d)  Section  4  -  Discussion  and  Summary:  a  review  and  summary  of  the  work  done  under  this 
task  in  context  of  its  objectives. 

e)  Appendix  A  -  Platform  Object  Route  Planning  Procedure:  a  description  of  the  approach  and 
procedure  that  was  used  to  generate  object  routes  that  were  implemented  in  STK. 

f)  Appendix  B  -  STK  Installation  &  Configuration  Instructions:  a  description  of  the  STK 
installation  and  scenario  configuration  process. 

g)  Appendix  C  -  Potential  Future  STK  Model  Specifications:  a  listing  of  the  specifications 
associated  with  potentially  future  desirable  attributes  that  could  be  implemented  in  the  Pro 
version  of  STK  with  custom  add-on  modules. 

h)  Appendix  D  -  Sample  Access  Calculations:  details  associated  with  the  sample  access 
calculations  that  were  performed  on  the  Task  185  STK  scenario  developed. 

i)  Appendix  E  -  Acronyms  and  Abbreviations:  a  table  containing  the  acronyms  and 
abbreviations  used  in  this  report. 

j)  Appendix  F  -  References:  a  list  of  references  made  in  this  report. 
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2  DESIGN 

This  section  of  the  report  contains  descriptions  of  the  activities  and  outcomes  associated  with 
the  conceptual  model  and  requirements  to  accomplish  the  objectives  of  this  work. 

2.1  Conceptual  Model 

The  conceptual  model  for  the  context  defined  in  the  Task  SOW  is  fairly  straight  forward.  It 
consists  of  friendly  platforms  with  sensors  conducting  surveillance  and  reconnaissance  on 
surface  targets  in  a  coastal  maritime  environment.  This  high-level  concept,  along  with  some 
initial  details,  is  depicted  in  Figure  2-1. 


Figure  2-1:  Operational  Level  Conceptual  Model 

The  next  level  of  detail  in  the  conceptual  model  takes  into  account  some  of  the  specific 
information  provided  in  the  Task  SOW  regarding  the  sensor  platforms  and  the  target  set.  The 
systems  level  conceptual  model  is  depicted  in  Figure  2-2. 
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Ground 

Stations 


Target  Platforms 


Figure  2-2:  System  Level  Conceptual  Model 

Having  established  conceptual  views  of  the  problem  space,  in  terms  of  objects  and  interactions, 
one  could  then  set  about  articulating  requirements  for  the  model.  The  next  section  of  this  report 
identifies  the  requirements  associated  with  the  objectives  of  this  task. 

2.2  Requirements 

The  Task  SOW  contained  statements  that  one  could  consider  as  high-level  requirements. 

Based  on  these  statements  in  conjunction  with  review  and  assessment  of  the  conceptual  model 
in  context  of  the  Task  objectives,  the  following  table  lists  the  functional  requirements. 
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Table  2-1:  Coastal  Surveillance  Baseline  Model  Functional  Requirements 


Requirement 

Serial 

Requirement  Statement 

RQ-01 

The  model  must  capture  the  full  three-dimensional  topography  of  the  Canadian  East 
and  West  Coasts 

RQ-02 

The  model  must  represent  the  following  platform  level  objects:  satellites,  aircraft, 
surface  vessels,  and  ground  facilities 

RQ-03 

The  model  must  represent  the  following  categories  of  sensors:  radio  frequency  (RF), 
electro-optic  (EO),  infrared  (IR),  and  visual 

RQ-04 

The  model  must  represent  RF-based  communication  transmitters  and  receivers 

RQ-05 

The  model  must  aggregate  (attach)  sensors,  transmitters  and  receivers  onto  platforms 
to  represent  operational  systems 

RQ-06 

The  model  must  represent  typical  movement  of  the  platform  categories,  such  as 
orbits,  mission  routes,  and  transit  routes 

RQ-07 

The  model  must  represent  a  specified  time  period 

RQ-08 

The  model  must  contain  twelve  sensor  platforms  consisting  of  a  mix  of  space,  air,  sea 
and  ground  facilities  (as  per  the  types  identified  in  Figure  2-2),  along  with  the 
appropriate  sensors  as  per  the  Annex  to  the  Task  SOW 

RQ-09 

The  model  must  contain  a  specified  number  (as  per  the  Annex  to  the  Task  SOW)  of 
target  platforms  consisting  of  a  mix  of  the  platform  types  identified  in  Figure  2-2 

RQ-10 

The  model  must  be  configured  to  permit  calculation  of  surveillance-relevant  metrics, 
such  as  time  on-station  for  air-based  sensors  and  revisit  period  for  space-based 
sensors 

Requirement  Statement 
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3  IMPLEMENTATION 

This  section  contains  descriptions  of  the  activities  and  outcomes  associated  with  the 
development  of  the  STK  model  required  under  this  work.  It  also  includes  observations  that  were 
made  regarding  constraints  and  limitations  associated  with  the  free  version  of  STK  10.1.3, 
which  was  used  to  conduct  this  work. 

3.1  Model  Development 

Development  of  the  Coastal  Surveillance  Baseline  Model  in  STK  was  done  in  two  main  steps: 

•  Scenario  Items;  and 

•  Object  Items. 

It  is  important  to  note  that  the  constraints  and  limitations  imposed  by  the  free  version  of  STK 
prevented  the  model  development  from  meeting  all  of  the  objectives  and  requirements.  The 
Annex  to  the  Task  SOW  identified  a  variety  of  platforms  and  specific  or  implied  sensors  that 
required  modelling  in  context  of  the  higher  level  objectives  associated  with  this  work.  Due  to  the 
constraints  and  limitations  none  of  the  specific  sensors  was  able  to  be  modelled.  In  addition, 
CAE  did  not  obtain  any  information  regarding  some  of  the  aspects  deemed  classified;  this  was  a 
conscious  decision  due  to  the  fact  that  the  work  was  severely  constrained  by  the  version  of 
software  in  use. 

Specific  constraints  and  limitations  are  addressed  in  the  subsequent  sections,  and  a  summary 
of  the  main  issues  is  captured  at  the  end  of  this  section  of  the  report. 

3.1.1  Scenario  Items 

The  Task  Technical  Authority  (TA)  identified  the  time  bounds  for  the  scenario  model  within  STK; 
the  start  date  and  end  date  were  set  appropriately,  at  the  STK  Scenario  level,  in  the  model. 

The  Task  SOW  indicated  the  need  for  the  model  to  capture  the  full  three-dimensional 
topography  of  the  Canadian  East  and  West  Coasts.  Subsequent  discussions  with  the  Task  TA 
defined  the  requirement  in  more  detail;  the  requirement  was  for  all  Canadian  coastlines  on  the 
East  and  West  Coasts,  as  well  as  a  minimum  of  20  nautical  miles  inland  from  the  coastlines. 
CAE  was  able  to  find  the  appropriate  topographical  data  to  support  this  requirement;  however,  it 
was  eventually  discovered  that  the  free  version  of  STK  does  not  permit  importing  terrain  data  for 
inclusion  in  the  model. 

To  help  identify  the  general  maritime  operating  areas  associated  with  Canadian  coastal 
surveillance,  CAE  used  map  images  that  were  obtained  in  the  public  domain  [1].  The  West 
Coast  portion  of  the  map  is  shown  in  Figure  3-1 .  This  helped  guide  the  placement  of  area  and 
platform  objects  and  entities  within  the  model. 
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Figure  3-1:  West  Coast  Area  of  Responsibility121 
3.1.2  Object  Items 

The  objects  in  the  STK  model  consist  of  elements  that  satisfy  the  concepts  depicted  in  Figure 
2-1  and  Figure  2-2,  as  well  as  the  requirements  listed  in  T able  2-1 . 

3. 1.2.1  Target  Platforms 

The  target  platforms  for  the  Coastal  Surveillance  Baseline  Model  consist  exclusively  of  surface 
vessels.  Within  this  group  there  are  three  main  categories  as  depicted  earlier  in  Figure  2-2. 

The  Task  SOW  required  the  baseline  model  to  contain  several  hundred  targets  distributed 
across  the  three  categories  of  surface  vessels;  the  standard  means  for  entering  ship  objects  into 
STK  for  this  many  vessels  over  the  3  month  scenario  period  would  have  been  very  time 
consuming  and  taken  much  longer  than  the  time  available  under  this  task.  Therefore,  CAE 
attempted  to  create  a  workflow,  supported  by  an  Excel  spreadsheet,  to  generate  ship  routes  in  a 


27  February  2015 


-7- 


5758-001  Version  01 


CAE 


DRDC  CORA  Task  #185 
Coastal  Surveillance  Baseline 
Model  Development 


text  file  format  that  can  be  imported  by  STK  through  the  ship  object’s  Basic  Route  properties 
dialogue.  A  general  description  follows  while  details  are  contained  in  Appendix  A. 

The  Excel  spreadsheet  made  use  of  STK’s  “Specific  Time”  Route  Calculation  Method  to  link  a 
series  of  latitude  and  longitude  points  together  to  form  a  route.  The  use  of  the  Excel 
spreadsheet  allowed  CAE  to  control  the  speed  and/or  time  for  a  given  distance.  The  Specific 
Time  method  was  also  the  method  that  allowed  the  simplest  implementation  of  objects  that 
needed  to  appear  stationary. 

However,  even  this  approach,  which  did  speed  the  process  somewhat,  did  not  provide  a  means 
to  generate  meaningful  routes  for  all  targets  in  the  contract  time  available.  The  result  was  that 
many  of  the  large  cargo  vessels  have  the  same,  overlapping  routes,  and  the  majority  of 
pleasure  craft  are  stationary  throughout  the  scenario  time  period. 

Table  3-1  identifies  the  number  of  each  category  of  target  platform  that  exist  in  the  STK  model 
as  delivered. 


Table  3-1:  Target  Platforms  -  Number  in  Model 


Vessel  Type 

Object  Name 

Sensor 

Configuration 

Number  of 
Type  in  Model 

Large  Vessel 

Cargo_Vessel_# 

AIS  On 

60 

Large  Vessel 

Cargo_Vessel_# 

AIS  Off 

60 

Fishing  Vessel  Small 

Fishing_Vessel_1 50ft_# 

AIS  On 

15 

Fishing  Vessel  Medium 

Fishing_VesseM  75ft_# 

AIS  On 

15 

Fishing  Vessel  Large 

Fishing_Vessel_200ft_# 

AIS  On 

15 

Fishing  Vessel  Extra  Large 

Fishing_Vessel_250ft_# 

AIS  On 

15 

Fishing  Vessel  Small 

Fishing_Vessel_1 50ft_# 

AIS  Off 

15 

Fishing  Vessel  Medium 

Fishing_VesseM  75ft_# 

AIS  Off 

15 

Fishing  Vessel  Large 

Fishing_Vessel_200ft_# 

AIS  Off 

15 

Fishing  Vessel  Extra  Large 

Fishing_Vessel_250ft_# 

AIS  Off 

15 

Pleasure  Craft  Small  &  Slow 

Sailboat_Small_# 

Not  Applicable 

15 

Pleasure  Craft  Small  &  Fast 

Motorboat_# 

Not  Applicable 

15 

Pleasure  Craft  Large  &  Slow 

Sailboat_Large_# 

Not  Applicable 

15 

Pleasure  Craft  Large  &  Fast 

Yacht_# 

Not  Applicable 

15 

A  common  sense  approach,  based  on  the  scenario  time  of  year,  was  taken  regarding 
distribution  of  the  numbers  of  each  type  of  target  and  the  geographical  location  within  the 
model.  For  example,  the  pleasure  craft  are  fewer  in  number  and  closer  to  docking  locations 
than  if  the  scenario  time-frame  had  been  set  during  less-stormy  months. 
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The  total  number  of  large  cargo  vessels  and  smaller  fishing  vessels  were  distributed  evenly. 
Both  object  types  represent  40  percent  of  the  target  objects  while  the  out  of  season  pleasure 
craft  only  represent  20  percent  of  the  object  targets. 

Further  details  for  each  category  of  target  are  contained  in  the  subsequent  paragraphs. 

Large  (Cargo)  Vessels 

The  large  cargo  vessels  were  created  by  inserting  a  default  Ship  object.  This  ship  object  was 
assigned  a  Threat  Freighter  visual  model  [31  ( threat_freighter.mdl ),  which  was  downloaded  from 
AGI’s  3D  model  repository.  No  additional  changes  were  made  to  the  basic  ship  object  other 
than  a  short  description  of  the  vessel. 

To  assist  in  generating  large  vessel  routes  that  aligned  closely  with  real  world  shipping,  CAE 
used  the  image  in  Figure  3-2,  which  depicts  present-day  density  of  commercial  shipping. 


Figure  3-2:  Present-Day  Commercial  Shipping  Routes  [4] 

As  per  the  Task  SOW,  some  of  the  large  vessels  were  to  incorporate  AIS  sensors.  The  free 
version  of  STK  does  not  permit  the  creation  of  Transmitter  and  Receiver  objects.  Therefore,  the 
intent  to  have  an  AIS  sensor  was  denoted  by  the  presence  of  a  generic  Sensor  object,  which 
has  no  specific  defining  parameters  that  hold  any  relevance  to  a  real  AIS  sensor.  The  Sensor 
name  is  either  “AIS_On”  or  “AIS_Off”  to  differentiate  between  targets  appropriately  as  per 
Figure  2-2. 

The  large  cargo  vessels  with  the  “AIS_On”  sensor  were  defined  in  the  scenario  as 
“Cargo_VesseM”  through  “Cargo_Vessel_60”.  The  large  cargo  vessels  with  the  “AIS_Off” 
sensor  were  defined  in  the  scenario  as  “Cargo_Vessel_61”  through  “Cargo_Vessel_120”. 
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A  variety  of  shipping  routes  were  generated  for  the  large  cargo  vessels.  Each  shipping  route 
was  generated  by  having  the  vessel  travel  between  two  or  more  of  the  port  cities  placed  within 
the  STK  model.  These  vessel  routes  do  not  necessarily  adhere  to  real  world  shipping  practices 
or  standards.  There  was  insufficient  information  and  time  to  implement  a  higher  fidelity  model. 

The  Excel  spreadsheet  method  was  used  by  CAE  to  generate  these  routes  to  implement  rest 
times  in  port  and  to  ensure  that  no  vessel  traveled  faster  than  20  knots,  which  was  arbitrarily 
selected.  Upon  arriving  in  port,  a  cargo  vessel  was  configured  to  stay  in  port  for  a  random 
amount  of  time  ranging  from  several  hours  to  several  days. 

The  active  port  cities  in  the  scenario  were  selected  based  on  being  either  commonly  known 
major  port  cities  on  the  Pacific  Ocean  or  active  port  cities  within  the  area  of  responsibility  (AOR). 
In  this  way,  each  cargo  vessel’s  time  within  the  AOR  was  maximized  while  still  attempting  to 
model  real-world  behaviour  as  best  as  possible.  Following  is  a  list  of  the  active  port  cities: 

•  Anchorage,  Alaska,  USA; 

•  Hong  Kong,  China; 

•  Honolulu,  Hawaii,  USA; 

•  Kitimat,  British  Columbia,  Canada; 

•  Los  Angeles,  California,  USA; 

•  Nanaimo,  British  Columbia,  Canada; 

•  Portland,  Oregon,  USA; 

•  Prince  Rupert,  British  Columbia,  Canada; 

•  San  Francisco,  California,  USA; 

•  Seattle,  Washington,  USA; 

•  Tacoma,  Washington,  USA; 

•  Vancouver,  British  Columbia,  Canada; 

•  Victoria,  British  Columbia,  Canada; 

•  Vladivostok,  Russia;  and 

•  Yokohama,  Japan. 

Originally,  20  different  shipping  routes  were  created  using  predefined  routes  between  ports  as  a 
basis  for  the  Excel  spreadsheet  route  planner.  These  routes  were  then  applied  to  the  first  set  of 
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cargo  vessels  having  the  “AIS_On”  sensor  (i.e.  Cargo_VesseM  through  Cargo_Vessel_20). 
These  20  shipping  routes  where  then  copied  and  modified  such  that  their  starting  ports  changed 
and  their  routes  were  reversed.  These  modified  routes  where  then  applied  to  the  first  set  of 
cargo  vessels  which  had  the  “AIS_Off”  sensor  (i.e.  Cargo_Vessel_61  through 
Cargo_Vessel_80). 

These  original  40  vessels  were  then  copied  to  populate  the  scenario  with  60  AIS_On  large 
cargo  vessels  and  60  AIS_Off  large  cargo  vessels.  Unfortunately,  there  was  insufficient 
contract  time  available  to  generate  unique  routes  for  all  cargo  ships.  The  remaining  cargo 
vessels  were  each  positioned  in  a  random  location  within  the  AOR  and  configured  to  remain 
stationary  for  the  duration  of  the  scenario. 

Fishing  Vessels 

The  fishing  vessels  were  created  by  inserting  a  default  Ship  object.  This  ship  object  was 
assigned  a  QST-35  Seaborne  Powered  Targets  (SEPTAR) [51  visual  model  ( septar.mdl ),  which 
was  downloaded  from  AGI’s  3D  model  repository.  No  additional  changes  were  made  to  the 
basic  ship  object  other  than  a  short  description  of  the  vessel.  This  generic  fishing  vessel  was 
then  copied  and  renamed  to  generate  the  four  different  type  of  fishing  vessels  based  on  length: 
150ft,  175ft,  200ft  and  250ft.  Currently,  only  the  object  name  distinguishes  the  different  fishing 
vessel  types.  This  is  mainly  due  to  the  STK  limitation  of  not  being  able  to  define  an  object’s 
physical  dimensions. 

As  per  the  T ask  SOW,  some  of  the  fishing  vessels  were  to  incorporate  AIS  sensors.  The  free 
version  of  STK  does  not  permit  the  creation  of  Transmitter  and  Receiver  objects.  Therefore,  the 
intent  to  have  an  AIS  sensor  was  denoted  by  the  presence  of  a  generic  Sensor  object,  which 
has  no  specific  defining  parameters  that  hold  any  relevance  to  a  real  AIS  sensor.  The  Sensor 
name  is  either  “AIS_On”  or  “AIS_Off”  to  differentiate  between  targets  appropriately  as  per 
Figure  2-2.  The  different  types  of  fishing  vessels  with  the  “AIS_On”  sensor  were  defined  in  the 

scenario  as  “Fishing_Vessel _ ###ft_1”  through  “Fishing_Vessel _ ###ft_15”.  The  large  cargo 

vessels  with  the  “AIS_Off”  sensor  were  defined  as  “Fishing_Vessel _ ###ft_16”  through 

“Fishing_Vessel _ ###ft_30”. 

A  variety  of  routes  were  generated  for  the  different  fishing  vessels.  Each  fishing  vessel  route 
was  generated  by  having  the  vessel  travel  from  a  home  port  in  the  AOR,  circle  an  area  in  AOR 
and  then  return  to  its  home  port.  These  routes  do  not  necessarily  adhere  to  real  world  fishing 
patterns,  practices  or  locations.  There  was  insufficient  information  and  time  to  implement  a 
higher  fidelity  model. 

The  Excel  spreadsheet  method  was  used  by  CAE  to  generate  these  routes  to  implement  rest 
times  at  port  and  to  ensure  that  no  vessel  traveled  faster  than  10  knots,  which  was  arbitrarily 
selected.  The  vessel  speeds  in  the  Excel  spreadsheet  were  randomized  for  each  leg  of  a 
fishing  route,  and  often  ranged  between  0.5  knots  and  9  knots.  Upon  arriving  in  port,  a  fishing 
vessel  was  configured  to  stay  in  port  for  a  random  amount  of  time  ranging  from  several  hours  to 
several  days. 
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Twenty  different  fishing  routes  were  generated  for  the  scenario.  These  routes  were  spread  out 
across  nine  different  port  cities  within  or  near  the  AOR.  Table  3-2  identifies  the  number  of 
fishing  routes  for  each  port  city. 


Table  3-2:  Target  Platforms  -  Fishing  Route  Breakdown 


Home  Port  City 

Number  of  Fishing  Routes 

Anchorage,  Alaska,  USA 

2 

Comox,  British  Columbia,  Canada 

3 

Kitimat,  British  Columbia,  Canada 

2 

Nanaimo,  British  Columbia,  Canada 

1 

Port  Hardy,  British  Columbia,  Canada 

4 

Prince  Rupert,  British  Columbia,  Canada 

2 

Tofino,  British  Columbia,  Canada 

3 

Vancouver,  British  Columbia,  Canada 

1 

Victoria,  British  Columbia,  Canada 

2 

The  routes  were  produced  by  using  the  STK  2D  Graphics  window’s  Measure  function  and  the 
CAE  Excel  spreadsheet.  The  Measure  function  was  used  to  quickly  generate  a  set  of  latitudes 
and  longitudes  to  layout  the  route,  and  the  Excel  spreadsheet  was  used  to  randomize  the  speed 
between  waypoints  as  well  as  the  rest  times  in  port. 

Pleasure  Craft 


The  four  different  pleasure  craft  types  were  originally  created  by  inserting  a  default  Ship  object. 
The  small  and  slow  pleasure  craft  type  was  defined  as  a  Small  Sailboat,  and  was  assigned  a 
Rubber  Boat  visual  model  [6]  (rubber_boat.mdl),  which  was  downloaded  from  AGI’s  3D  model 
repository.  The  small  and  fast  pleasure  craft  type  was  defined  as  a  Motorboat,  and  was  also 
assigned  the  Rubber  Boat  model.  The  large  and  slow  pleasure  craft  type  was  defined  as  a 
Large  Sailboat,  and  was  also  assigned  the  Rubber  Boat  model.  The  large  and  fast  pleasure 
craft  type  was  defined  as  a  Yacht,  and  was  assigned  a  Cruise  Liner  visual  model  [7] 
(cruiserjiner.mdl),  which  was  downloaded  from  AGI’s  3D  model  repository. 

The  pleasure  craft  objects  had  no  changes  made  to  the  basic  ship  object  other  than  a  short 
description  of  the  vessel.  Currently,  only  the  object  name  and  3D  models  distinguish  between 
the  different  pleasure  craft  types.  This  is  due  to  the  STK  limitation  of  being  unable  to  define  an 
object’s  physical  dimensions. 
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Unfortunately,  there  was  insufficient  time  to  generate  unique  routes  for  the  pleasure  craft 
objects.  The  pleasure  craft  vessels  were  positioned  in  random  locations  close  to  the  coast 
within  the  AOR  and  configured  to  remain  stationary  for  the  duration  of  the  scenario. 

3. 1.2.2  Sensor  Platforms 

Satellite  Platforms  and  Sensors 


The  STK  application  comes  with  access  to  an  unclassified  database  of  satellites  and  other 
space-based  objects  (such  as  the  International  Space  Station).  The  parametric  data  that 
defines  the  orbits  of  these  assets  (Element  Sets)  is  well-known  and  relatively  fixed  due  to  the 
nature  of  orbital  operations.  Inclusion  of  the  relevant  and  available  satellite  platforms  in  the  STK 
model  was  relatively  straight  forward;  the  appropriate  object  was  identified  in  the  database  and 
then  imported  into  the  STK  scenario  for  the  relevant  time  period. 

The  Task  SOW  identified  RadarSat2  (RS2)  as  a  required  space-based  asset.  The  STK  satellite 
database  has  a  pre-defined  object  for  RS2  (Space  Surveillance  Catalogue  (SSC)  Number 
32382),  as  well  as  an  apparently  full  suite  of  sensors  mounted  on  the  satellite.  The  orbital  path 
of  this  object  was  imported  into  the  STK  model  for  the  relevant  time  period 

Investigation  on  the  internet  in  the  area  of  space-based  AIS  capabilities  uncovered  information 
at  the  following  URL:  https://icode-mda.qooqlecode.com/svn/wiki/LessonAIS.wiki.  This  website 
contained  information  identifying  specific  space-based  assets  (by  name  and  SSC  number)  that 
host  AIS  sensors.  The  specific  names  and  numbers  are  as  indicated  in  Table  3-3. 

Table  3-3:  AIS  Related  Satellites 


Asset  Name 

SSC# 

AprizeSat-3 

35686 

AprizeSat-6 

37793 

GOES-13 

29155 

GOES-15 

36411 

ISS 

25544 

ResourceSat-1 

28051 

VesselSat-1 

37840 

VesselSat-2 

38047 

The  space-based  asset  named  ExactView-1  (SSC  #  38709)  was  also  found  in  the  STK  satellite 
database;  the  company  exactEarth  [8]  operates  a  satellite  constellation  called  exactViewTM  that 
hosts  AIS  sensors.  Therefore,  this  object  and  the  objects  listed  in  Table  3-3  were  imported  into 
the  STK  model. 
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Aircraft  Platforms  and  Sensors. 


The  STK  application  allows  the  user  to  define  aircraft  objects  by  specifying  a  route  that  consists 
of  a  series  of  waypoints;  the  route  is  bounded  by  a  starting  location  and  an  ending  location.  The 
waypoints  in  an  aircraft  route  can  be  established  based  on  time  (in  which  case  the  speed  is 
calculated)  or  based  on  speed  (in  which  case  the  time  is  calculated);  route  waypoints  are 
defined  by  the  following  parameters: 

•  Geographic  position  (latitude  and  longitude); 

•  Altitude; 

•  Time  (in  universal  coordinated  time  or  UTC)  within  the  scenario;  and 

•  Speed  along  the  route. 

Each  specific  aircraft  object  is  uniquely  identified  by  its  object  name;  the  aircraft  objects  included 
in  the  STK  model  as  delivered  are  identified  in  Table  3-4. 

Table  3-4:  Aircraft  Objects 


Object  Name 


CP140_Aurora 
PAL_Dash-8 
Generic  Sensor 


In  the  real  world,  the  CPI 40  assets  are  located  at  19  Wing  at  Canadian  Forces  Base  (CFB) 
Comox  on  Vancouver  Island.  In  the  STK  model,  the  CPI 40  object  has  its  origin  at  this  location 
and  it  was  assigned  two  arbitrary  (unclassified)  routes  within  the  west  coast  AOR  during  the 
time  period  of  the  scenario.  The  CPI 40  object  travels  these  routes  at  an  altitude  of  20,000ft 
and  a  speed  of  320  knots  for  no  more  than  a  period  of  1 0  hours.  The  CPI  40  travels  one  of  the 
two  routes  on  average  twice  each  week  at  random  times.  These  routes  and  the  randomized 
times  were  generate  using  the  CAE  Excel  spreadsheet. 

The  CPI 40  object  was  created  by  adding  a  Lockheed  P-3C_Orion  profile  from  the  STK  10 
aircraft  database.  The  P-3C_Orion  profile  was  renamed  to  CP140_Aurora.  No  additional 
changes  to  the  object  were  made  due  to  the  STK  limitation  of  being  unable  to  define  an  object’s 
dimensions. 

The  CPI 40  was  then  provided  with  six  different  unclassified,  generic  sensor  objects.  These 
sensor  objects  included  an  AIS  placeholder  object,  an  EO/IR  sensor  object,  a  basic  pilot/crew 
Visual  sensor  object  and  three  different  Radar  objects  to  model  the  field  of  regard  for  the  radar 
on  the  CP140. 

Given  the  limitations  of  the  free  version  of  STK  the  model  development  for  the  CPI 40  radar 
sensor  required  two  components: 
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•  Definition  and  assignment  of  three  separate  generic  sensors  to  provide  visual  representation 
of  the  radar  field  of  regard  (similar  to  the  depiction  in  Figure  3-3);  and 


Figure  3-3:  Generic  Sensor  Visualization 

•  Definition  of  aircraft-object-level  Constraints  in  the  Basic  Properties  window  (Figure  3-4)  as  a 
simplistic  approach  to  modelling  the  radar  sensor  envelope  to  enable  straight  forward,  line- 
of-sight  Access  calculations  against  targets  in  the  model. 


Figure  3-4:  Basic  Constraints  for  Access  Calculations 
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The  parameters  used  to  define  the  CPI 40  generic  sensor  objects  in  the  STK  model  are 
identified  in  Table  3-5. 

Table  3-5:  CP140  Generic  Sensor  Definition  Parameters 


Object  Name 

Sensor  Type 

Cone  Half  Angle  (deg) 

Vertical  Half  Angle  (deg) 

Horizontal  Half  Angle  (deg) 

Pointing  Azimuth  (deg) 

Pointing  Elevation  (deg) 

Azimuth  Angle  Min  (deg) 

Azimuth  Angle  Max  (deg) 

Elevation  Angle  Min  (deg) 

Elevation  Angle  Max  (deg) 

Range  Max  (km) 

CP140EOIR 

Simple  Conic 

90 

0 

90 

50 

CP140_Radar_L 
eft Arc 

Rectangular 

15 

15 

-150 

15 

-120 

120 

-80 

0 

300 

CP140_Radar_ 
Main Arc 

Rectangular 

90 

15 

0 

15 

-120 

120 

-80 

0 

300 

CP140_Radar_L 
eft Arc 

Rectangular 

15 

15 

150 

15 

-120 

120 

-80 

0 

300 

CP140 Visual 

Simple  Conic 

90 

0 

90 

10 

In  the  STK  model,  the  PAL_Dash-8  object  has  its  origin  at  Comox  [9]  and  it  was  assigned  two 
arbitrary  (unclassified)  routes  along  the  west  coast  AOR  during  the  time  period  of  the  scenario. 
The  PAL_Dash-8  object  travels  these  routes  at  an  altitude  of  22,500ft [10]  and  a  speed  of  290 
knots  [111  for  no  more  than  a  period  of  6  hours.  The  PAL_Dash-8  travels  one  of  the  two  routes 
approximately  once  each  week  at  random  times.  These  routes  and  the  randomized  times  were 
generated  using  the  CAE  Excel  spreadsheet. 

The  PAL_Dash-8  object  was  created  by  inserting  a  default  Aircraft  object.  This  aircraft  object 
was  assigned  a  Beechcraft  1900  Commuter 1121  model  ( commuter.mdl ),  which  was  downloaded 
from  AGI’s  3D  model  repository.  No  additional  changes  were  made  to  the  basic  aircraft  object 
other  than  a  short  description  of  the  aircraft. 

The  PAL_Dash-8  was  then  provided  with  four  (4)  different  unclassified  sensor  objects.  These 
sensor  objects  include  an  AIS  placeholder  object,  an  IR  sensor  object,  a  basic  pilot/crew  Visual 
sensor  object  and  a  Radar  sensor  object.  These  sensors  were  built  using  basic  unclassified 
information  from  the  Canadian  Department  of  Fisheries  and  Oceans  [13]. 

The  parameters  used  to  define  the  PAL_Dash-8  generic  sensor  objects  in  the  STK  model  are 
identified  in  Table  3-6. 
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Table  3-6  PAL  Dash-8  Generic  Sensor  Definition  Parameters 


Object  Name 

Sensor  Type 

Cone  Half  Angle  (deg) 

Pointing  Azimuth  (deg) 

Pointing  Elevation  (deg) 

Range  Max  (km) 

PAL FLIR 

Simple  Conic 

90 

0 

90 

50 

PAL Search Radar 

Simple  Conic 

90 

0 

90 

320 

PAL Visual 

Simple  Conic 

90 

0 

90 

10 

In  the  STK  model,  a  generic  Aircraft  object  was  created  to  represent  the  behaviour  of  an  “all- 
seeing"  sensor;  this  was  done  at  the  request  of  the  task  TA.  This  object  was  placed  at  an 
altitude  of  200  km  over  the  AOR  and  configured  to  remain  stationary  for  the  duration  of  the 
scenario  period.  The  aircraft  object  was  provided  with  a  “Generic_Sensor”  sensor  object  to 
model  the  desired  behaviour. 

Surface  Vessel  Platforms  and  Sensors 


The  STK  application  allows  the  user  to  define  Ship  objects  in  a  similar  fashion  as  for  Aircraft 
objects  with  the  key  difference  being  that  there  is  no  altitude  parameter. 

The  Halifax_Class  object  was  created  using  information  obtained  in  the  public  domain.  It  was 
created  by  inserting  a  default  Ship  object  in  the  scenario.  This  Ship  object  was  assigned  a  Type 
23  Frigate  [14]  visual  model  (type_23_frigate.mdl),  which  was  downloaded  from  AGI’s  3D  model 
repository.  No  additional  changes  were  made  to  the  basic  ship  object  other  than  a  short 
description  of  the  vessel. 

The  Halifax_Class  was  provided  with  four  (4)  different  generic  sensor  objects.  These  sensor 
objects  include  an  AIS  placeholder  object,  an  IR  sensor  object,  a  basic  crew  Visual  sensor 
object  and  a  Radar  sensor  object.  These  sensors  were  defined  using  basic  unclassified 
information  from  several  different  sources  [151[161[171. 
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Table  3-7:  Halifax  Class  Generic  Sensor  Definition  Parameters 


Object  Name 

Sensor  Type 

Cone  Half  Angle  (deg) 

Pointing  Azimuth  (deg) 

Pointing  Elevation  (deg) 

Range  Max  (km) 

Halifax AN SPS 505 

Simple  Conic 

90 

0 

90 

88 

HalifaxJR 

Simple  Conic 

90 

0 

90 

10 

Halifax Visual 

Simple  Conic 

90 

0 

90 

10 

In  the  STK  model,  the  Halifax_Class  object  uses  CFB  Esquimalt  as  its  home  port.  The 
Halifax_Class  object  repeats  a  single  arbitrary  route  within  the  west  coast  AOR  during  the  time 
period  of  the  scenario.  It  travels  this  route  at  a  speed  of  10  knots  for  a  period  of  approximately 
26  days  then  returns  to  port  for  a  randomized  rest  period  of  between  four  (4)  and  seven  (7) 
days.  These  routes  and  the  randomized  times  were  generated  using  the  CAE  Excel 
spreadsheet. 

The  Kingston_Class  object  was  created  using  information  obtained  in  the  public  domain  similar 
to  the  Halifax_Class  object.  The  Kingston_Class  object  was  assigned  an  Offshore  Patrol  Cutter 
(OPC)  [18]  visual  model  (opc.mdl),  which  was  downloaded  from  AGI’s  3D  model  repository.  No 
additional  changes  were  made  to  the  basic  ship  object  other  than  a  short  description  of  the 
vessel. 

The  Kingston_Class  was  provided  with  three  (3)  different  generic  sensor  objects.  These  sensor 
objects  include  an  AIS  placeholder  object,  a  Radar  sensor  object,  and  a  basic  crew  Visual 
sensor  object.  These  sensors  were  built  using  basic  unclassified  information  from  several 
different  sources  [19][20][21]. 
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Table  3-8:  Kingston_Class  Generic  Sensor  Definition  Parameters 


In  the  STK  model,  the  Kingston_Class  object  uses  CFB  Esquimalt  as  its  home  port.  The 
Kingston_Class  object  repeats  a  single  arbitrary  route  along  the  west  coast  of  the  AOR  during 
the  time  period  of  the  scenario.  It  travels  this  route  at  a  speed  of  8  knots  for  a  period  of 
approximately  13  days  then  returns  to  port  for  a  randomized  rest  period  of  between  three  (3) 
and  five  (5)  days.  These  routes  and  the  randomized  times  were  generate  using  the  CAE  Excel 
spreadsheet. 

Ground  Stations 

A  single  generic  STK  Facility  called  AIS_Ground_Station  was  added  to  the  scenario,  and  placed 
in  the  CFB  Comox  area.  A  place  holder  “AIS_Rx”  sensor  was  attached  to  the  facility.  No 
additional  work  was  done  to  model  this  object  due  the  lack  of  the  STK  Communications  Module 
and  the  detailed  specifications  concerning  capability  and  placement  of  such  a  facility. 

A  generic  STK  Facility  was  also  added  to  the  scenario,  and  placed  in  the  CFB  Esquimalt  area. 

3. 1.2. 3  Area  Target  Objects 

STK  allows  users  to  instantiate  and  define  objects  to  represent  geographic  areas  on  the  surface 
of  the  earth;  these  are  known  as  Area  Target  Objects.  STK  comes  with  a  set  of  pre-defined 
Area  Target  Objects  based  primarily  on  political  boundaries;  users  are  also  able  to  define 
custom  areas  through  free-form  specification  of  bounding  points. 

In  the  current  STK  model,  a  set  of  areas  was  defined  for  two  reasons: 

•  To  provide  visual  assistance  during  ship  and  aircraft  route  planning;  and 

•  To  support  the  execution  of  sample  Access  calculations. 
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The  second  reason  will  become  more  important  to  future  work  if  the  STK  Coverage  module  is 
obtained;  this  will  facilitate  the  execution  of  detailed  coverage  analyses,  for  which  Area  Target 
Objects  are  required  when  defining  the  coverage  areas. 

The  areas  added  to  the  current  STK  model  were: 

•  An  approximation  of  the  MARPAC  region,  using  13  Area  Target  Objects,  based  on  public 
domain  data  [22]  (as  per  Figure  3-1)  depicted  in  Figure  3-5  below; 

•  The  main  body  of  the  STK  pre-defined  Canadian  region; 

•  The  STK  pre-defined  continental  United  States;  and 

•  The  STK  pre-defined  Alaska  area. 

The  Canadian,  United  States  and  Alaska  regions  were  imported  through  STK’s  “Select 
Countries  and  US  States”  area  target  creation  method.  The  MARPAC  regions  were 
implemented  manually  through  rough  estimations  of  appropriate  latitudes  and  longitudes. 


Figure  3-5:  MARPAC  Region  Area  Target  Objects 
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3. 1.2.4  Places 

STK  allows  users  to  instantiate  and  define  objects  to  represent  specific  geographic  locations  on 
the  surface  of  the  earth;  these  are  known  as  Place  Objects.  STK  comes  with  a  set  of  pre¬ 
defined  Place  Objects  based  primarily  on  cities;  users  are  also  able  to  define  custom  places 
through  free-form  specification  of  points. 

In  the  current  STK  model,  a  large  number  of  places  were  added  to  the  scenario  to  facilitate 
planning  and  analysis.  The  places  added  to  the  scenario  include: 

•  Major  cities  within  the  AOR; 

•  A  set  of  Canadian  Forces  Bases; 

•  Notable  checkpoints  for  the  design  of  shipping  routes;  and 

•  Major  port  cities  on  the  Pacific  Ocean  [231. 

The  Place  Objects  where  added  via  the  STK  City  Database  or  as  a  generic  place,  which  was 
provided  with  an  appropriate  latitude  and  longitude  acquired  from  Wikipedia. 

3.2  Model  Limitations 

Following  is  a  list  of  limitations  associated  with  the  free  version  of  STK. 

•  One  cannot  directly  import  terrain  data  such  as  Digital  Terrain  Elevation  Data  (DTED)  and 
Digital  Elevation  Maps  (DEMs);  one  needs  the  STK  Pro  version  to  enable  this  feature. 

•  For  sensors,  one  is  limited  to  defining  simple  conic  and  rectangular  sensors  with  no  ability  to 
identify  or  define  operating  parameters  related  to  the  spectrum  within  which  the  sensor 
operates  (e.g.  RF,  IR).  Furthermore,  the  simple  sensor  is  fixed  in  azimuth  and  elevation  (a 
“staring”  sensor)  meaning  it  cannot  be  set-up  to  scan  in  any  fashion.  Implementation  of 
specific  RF  sensors  requires  purchase  of  the  STK  Radar  add-on  module. 

•  One  cannot  define  communication  related  systems  (transmitters  and  receivers),  and  hence 
there  was  no  ability  to  define  AIS  objects  in  the  current  version  of  the  model. 

•  One  cannot  perform  coverage  analyses;  for  this  one  needs  to  purchase  the  STK  Coverage 
add-on  module,  which  then  facilitates  the  definition  of  area  targets  and  figures  of  merit  to 
support  coverage  calculations. 

Following  is  a  list  of  observations  associated  with  STK  in  general. 

•  In  general,  there  is  no  manner  in  which  one  can  explicitly  define  an  object’s  physical  size  or 
mass.  If  one  were  to  purchase  the  STK  SatPro  or  Astrogator  add-on  modules,  then  one 
obtains  access  to  the  Mass  option  for  satellite  objects;  in  addition  through  use  of  the  STK 
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Aircraft  Mission  Modeler  add-on  module  one  can  configure  aircraft  fuel  tank  weights. 
However,  these  discrete  add-on  options  do  not  apply  to  objects  in  general. 

•  There  is  no  means  to  “bulk  copy  /  assign”  a  sensor  (or  similar)  object  to  existing  platform 
objects  (aircraft,  satellites,  ships).  In  the  case  where  one  defines  a  sensor  or 
communications  object  (such  as  an  AIS  transmitter)  that  will  exist  on  several  different 
platforms,  one  must  assign  (using  a  copy  and  paste  function)  the  object  to  each  platform 
individually.  Using  this  approach,  STK  assigns  each  “pasted”  sensor  a  unique  name  by 
sequentially  incrementing  an  appended  integer.  One  can  then  amend  the  assigned  names 
so  that  all  sensors  that  are  of  the  same  configuration  have  the  same  name.  In  this  case, 
one  must  be  aware  that  any  changes  made  to  any  of  the  sensors  with  that  name,  when 
saved  (at  the  sensor  level)  will  then  apply  to  all  sensors  holding  that  name. 

3.3  Model  Use  -  Analysis 

The  higher  level  objective  of  the  MARPAC  Operational  Research  Team,  which  this  task  is 
intended  to  support  in  part,  is  research  and  analysis  associated  with  coastal  surveillance.  The 
Task  SOW  indicated  a  need  to  report  on  characteristics  relevant  to  the  domain  of  coastal 
surveillance  that  can  be  addressed  by  a  tool  such  as  STK;  these  include  items  such  as  time  on 
station  for  an  air-based  sensor  and  revisit  period  for  a  space-based  sensor.  Although  STK  is 
highly  suitable  for  this  type  of  analysis,  based  on  its  advanced  geometry  engine  and  system 
modelling,  the  free  version  of  STK  limits  the  type  of  analytical  calculations  that  can  be 
performed.  Nonetheless,  CAE  configured  and  ran  some  of  the  basic  Access  calculations  that 
are  possible  in  the  free  version  of  the  tool;  descriptions  of  the  computations  performed  are  in  the 
following  sections,  while  details  associated  with  the  output  are  contained  in  Appendix  D. 

Under  constraints  of  tool  functional  limitations  and  time  available,  CAE  was  able  to  run  Access 
calculations  in  two  general  categories:  Geographic-Based  Access  and  Target-Based  Access. 

3.3.1  Geographic-Based  Access 

Simple  Geographic-Based  Access  calculations  involve  analysis  as  to  when  a  platform  object 
(aircraft,  satellite,  ship)  is  within  line  of  site  of  a  point  or  area  on  the  surface  of  the  earth.  In  the 
available  version  of  STK  one  is  able  to  invoke  these  simple,  geometry-based  calculations,  which 
can  also  take  into  account  any  Basic  Constraints  that  may  have  been  defined  for  a  particular 
object  (such  as  those  defined  for  the  CPI 40  Aircraft  object  depicted  in  Figure  3-4).  Since 
detailed  terrain  and  feature  data  cannot  be  imported  into  the  free  version  of  STK,  terrain 
masking  limitations  cannot  be  taken  into  account;  the  only  earth-based  constraint  that  is 
accounted  for  is  the  curvature  of  the  earth  based  on  the  inherent  earth  ellipsoid  model  inherent 
to  STK  (selected  as  WGS-84). 

To  perform  Geographic-Based  Access  calculations,  one  must  first  define  an  appropriate 
geographical  area  (as  STK  Area  Target  Objects)  against  which  Access  calculations  can  then  be 
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run1.  This  was  done  as  per  the  description  in  Section  3. 1.2. 3.  The  next  step  is  to  identify  the 
platform  objects  of  interest  for  the  Access  calculations.  For  the  purposes  of  this  task,  the 
aircraft  and  satellite  platform  objects  were  used.  Examples  on  the  configuration  of  and  results 
from  these  Access  calculations  are  contained  in  Appendix  D. 

3.3.2  Target-Based  Access 

Simple  Target-Based  Access  calculations  involve  analysis  as  to  when  a  platform  object  (aircraft, 
satellite,  ship)  is  within  line  of  site  of  one  or  more  other  platform  objects.  In  the  available  version 
of  STK  one  is  able  to  invoke  these  simple,  geometry-based  calculations,  which  can  also  take 
into  account  any  Basic  Constraints  that  may  have  been  defined  for  a  particular  object.  Since 
detailed  terrain  and  feature  data  cannot  be  imported  into  the  free  version  of  STK,  terrain 
masking  limitations  cannot  be  taken  into  account;  the  only  earth-based  constraint  that  is 
accounted  for  is  the  curvature  of  the  earth  based  on  the  inherent  earth  ellipsoid  model  inherent 
to  STK  (selected  as  WGS-84). 

STK  is  capable  of  calculating  when  sensors  are  able  to  see  (detect)  specified  targets  based  on 
geometry,  as  well  as  sensor  and  target  characteristics;  the  computations  can  also  take  into 
consideration  a  variety  of  environmental  factors  if  desired.  However,  these  more  sophisticated 
analyses  require  STK  Pro  and  a  series  of  add-on  modules  (such  as  Communications,  Radar 
and  Coverage)  that  must  be  purchased. 

With  the  tool  available,  CAE  conducted  some  investigations  and  experimented  with  some 
simplistic  calculations.  The  first  calculations  were  run  using  the  CPI 40  Aircraft  Object  against 
the  full  set  of  Cargo  Vessel  Objects  for  the  duration  of  the  scenario;  the  result  produced  a  very 
large  number  of  Accesses  that  were  considered  too  numerous  for  inclusion  in  this  report. 
Therefore,  the  Access  was  reconfigured  to  cover  only  the  first  two  weeks  of  scenario  time  and 
only  the  first  10  Cargo  Vessel  Objects.  The  results  were  more  manageable  but  this  activity 
demonstrated  that  unless  the  analyst  is  interested  in  a  specific  target  of  interest,  object-to-object 
analysis  may  not  be  the  most  suitable  in  STK.  Given  the  author’s  past  experience  with  STK,  as 
well  as  videos  viewed  through  the  AGI  website,  it  is  likely  of  better  use  for  the  model  to  be 
configured  to  perform  area  coverage  calculations,  which  require  the  STK  Coverage  module. 
Some  details  on  this  module  are  contained  in  Appendix  C. 

Attempts  were  made  to  conduct  Ship  Object-based  Access  calculations;  however,  problems 
were  encountered  with  the  model  as  originally  configured  in  that  “No  Access  Found”  results 
were  generated.  It  was  believed  that  this  was  due  to  the  manner  in  which  STK  represents  and 
places  Ship  Objects  on  the  STK  Globe.  AGI  Technical  Support  was  contacted  to  determine  the 
source  of  the  issue  and  to  see  if  there  was  a  means  to  allow  access  calculations  to  be  done  for 
Ship  Objects.  AGI  Technical  Support  confirmed  that  within  STK  default  Ship  Objects  cannot 
see  one  another  due  to  the  curvature  of  the  earth  because  Ship  Objects  are  placed  as  point 
objects  directly  on  the  surface  of  the  earth.  However,  in  the  Basic  Constraints  properties  of  the 
Ship  Object,  one  can  deactivate  the  Line  of  Sight  constraint,  which  essentially  “removes  the 
earth”  as  a  line  of  sight  barrier  to  Access  calculations.  AGI  Technical  Support  recommended 


Note  that  STK  Pro  along  with  the  STK  Coverage  module  provides  the  ability  to  conduct  finer  coverage 
calculations  based  on  grid  patterns,  defined  figures  of  merit  and  specific  sensor  assignments;  however,  this  was 
not  possible  under  this  task.  Further  details  are  contained  in  Appendix  C. 
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this  approach  coupled  with  specification  of  a  small  negative  value  minimum  elevation  angle 
constraint  could  be  used  as  a  means  to  allow  Access  calculations  to  “look  down”  from  the  Ship 
Object’s  perspective  (Figure  3-6) [24].  In  addition,  any  other  Ship  Objects  within  the  STK 
scenario  that  will  be  used  as  targets  for  Access  calculations  must  also  have  the  Line  of  Sight 
option  deselected  in  Basic  Constraints;  however,  there  is  no  need  to  set  a  minimum  elevation 
for  these  objects.  This  work-around  was  implemented  in  the  STK  model  as  a  last  minute 
change;  Access  calculations  were  quickly  tested  and  proved  to  be  successful. 


Figure  3-6:  Ship  Object  Basic  Constraints  for  Access  Calculations 
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4  DISCUSSION  AND  SUMMARY 

This  section  of  the  report  contains  a  review  and  summary  of  the  work  done  under  this  task  in 
context  of  its  objectives. 

The  top-level  objective  of  this  work  was  presented  clearly  through  the  Task  SOW  and 
discussions  with  the  task  TA  during  the  kick  off  meeting  and  subsequent  exchanges  during 
course  of  the  work.  It  was  identified  early  on  that  there  were  going  to  be  limitations  in  what 
could  be  achieved  due  to  constraints  imposed  by  the  free  version  of  STK.  Notwithstanding  this, 
the  early  conceptual  phases  of  the  work  were  approached  from  an  implementation  independent 
perspective  in  the  mindset  that  more  sophisticated  versions  of  the  STK  platform  may  be 
available  in  the  future.  As  such,  the  conceptual  models  produced  will  prove  reusable  if  follow-on 
work  is  conducted. 

Model  implementation  proceeded  with  the  main  focus  on  creating  baseline  object  profiles  that 
could  be  enhanced  in  the  future.  From  a  target  platform  perspective,  all  required  objects  (300 
targets  consisting  of  a  mix  of  types)  were  generated  as  best  as  possible  in  the  current  model. 
From  a  sensor  platform  perspective  a  different  approach  was  taken,  the  main  reason  being  that 
these  platforms  were  intended  to  host  more  sophisticated  sensor  objects  and  creation  of 
multiple  simplified  objects  would  only  increase  the  amount  of  re-work  required  in  the  future. 
Therefore,  the  current  model  contains  only  a  single  instance  of  each  of  the  aircraft  and  ship 
sensor  platforms,  with  generic  sensor  child-objects  as  placeholders  for  the  more  sophisticated 
sensor  objects  if  enhanced  versions  of  STK  are  acquired  in  the  future.  The  satellite  objects 
identified  earlier  in  the  report  were  imported  as-is  from  the  existing  STK  Satellite  Object 
Database  and  propagated  for  the  duration  of  the  scenario  period. 

In  creating  the  target  platforms,  it  was  observed  that  STK  is  not  necessarily  well-suited  for 
generating  object  routes  for  long  periods  of  time  (such  as  weeks  and  months)  other  than  orbital 
objects  for  which  the  built-in  orbital  propagator  accomplishes  this  task.  The  use  of  the  Aircraft 
Mission  Modeler  may  ease  this  activity  for  Aircraft  Objects;  however,  CAE  was  not  able  to 
explore  this  option  because  it  is  not  available  in  the  free  version.  Nonetheless,  this  would  not 
address  the  challenges  associated  with  Ship  or  Ground  based  objects. 

STK  also  did  not  seem  well-suited  for  organizing  large  numbers  of  objects  over  long  periods  of 
time.  There  is  no  apparent  method  for  grouping  categories  of  objects  in  a  hierarchical  or  other 
fashion;  all  scenario  objects  are  placed  at  the  same  level  within  the  scenario,  which  can  make 
navigating  the  objects  challenging  and  cumbersome  in  the  STK  Object  Browser  when  the 
number  of  objects  is  large.  Although  it  was  not  available  in  the  free  version  of  STK,  CAE  is 
aware  that  there  is  a  Constellation  Object  that  can  be  used;  the  STK  Help  files  provide 
indication  that  Constellation  groups  can  be  created  using  any  object  types  but  CAE  was  not  able 
to  verify  or  experiment  with  this  option.  There  is  potential  that  Constellation  Objects  might  make 
object  management  for  analysis  somewhat  easier.  This  should  be  investigated  if  an  enhanced 
version  of  STK  is  acquired. 

In  Section  2.2  of  this  report  the  set  of  functional  requirements  derived  for  this  work  were  listed  in 
Table  2-1 .  This  section  of  the  report  provides  an  overview  assessment  of  whether  or  not  these 
requirements  were  met.  This  information  is  contained  in  Table  4-1  below. 
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Table  4-1:  Requirements  Verification  Status 


Requirement 

Serial 

Requirement  Statement 

Requirement  Status 

RQ-01 

The  model  must  capture  the  full  three- 
dimensional  topography  of  the  Canadian 

East  and  West  Coasts 

Not  Met 

The  free  version  of  STK  is  unable  to  import 
terrain  data 

RQ-02 

The  model  must  represent  the  following 
platform  level  objects:  satellites,  aircraft, 
surface  vessels,  and  ground  facilities 

Met 

The  model  represents  the  types  of  objects 
specified 

RQ-03 

The  model  must  represent  the  following 
categories  of  sensors:  radio  frequency 
(RF),  electro-optic  (EO),  infrared  (IR),  and 
visual 

Partially  Met 

The  free  version  of  STK  can  only  generate 
simple  generic  sensors 

RQ-04 

The  model  must  represent  RF-based 
communication  transmitters  and  receivers 

Not  Met 

The  free  version  of  STK  is  unable  to 
represent  transmitters  and  receivers 

RQ-05 

The  model  must  aggregate  (attach)  sensors, 
transmitters  and  receivers  onto  platforms  to 
represent  operational  systems 

Partially  Met 

The  model  has  generic  sensors  attached 
where  suitable  but  does  not  represent 
operational  systems 

RQ-06 

The  model  must  represent  typical 
movement  of  the  platform  categories  such 
as  orbits,  mission  routes,  and  transit  routes 

Met 

The  model  incorporates  orbits  (satellites), 
mission  routes  (sensor  platforms)  and  transit 
routes  (targets) 

RQ-07 

The  model  must  represent  a  specified  time 
period 

Met 

The  model  covers  the  time  period  specified 
in  the  Task  SOW 

RQ-08 

The  model  must  contain  twelve  sensor 
platforms  consisting  of  a  mix  of  space,  air, 
sea  and  ground  facilities  (as  per  the  types 
identified  in  Figure  2-2),  along  with  the 
appropriate  sensors  as  per  the  Annex  to  the 
Task  SOW 

Partially  Met 

The  model  contains  15  sensor  platforms 
consisting  of  a  mix  but  it  does  not  contain 
properly  modelled  sensors  due  to  limitations 
of  the  free  version  of  STK 

RQ-09 

The  model  must  contain  a  specified  number 
(as  per  the  Annex  to  the  Task  SOW)  of 
target  platforms  consisting  of  a  mix  of  the 
platform  types  identified  in  Figure  2-2 

Met 

The  model  contains  the  requisite  number  of 
target  platforms,  several  of  which  have 
suitable  routes  assigned  to  them. 

RQ-10 

The  model  must  be  configured  to  permit 
calculation  of  surveillance-relevant  metrics 
such  as  time  on-station  for  air-based 
sensors  and  revisit  period  for  space-based 
sensors 

Partially  Met 

The  free  version  of  STK  has  limited  analytic 
capability.  Simple  access  calculations  were 
performed  where  able 

STK  did  “crash”  several  times  on  the  development  platform  that  was  being  used.  The  author  is 
aware  from  past  experience  with  STK  that  the  application  can  be  demanding  on  the  host 
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platform  from  a  couple  of  different  perspectives.  If  the  scenario  has  many  sophisticated 
visualization  aspects  such  as  high  resolution  terrain  and  imagery,  as  well  as  sophisticated 
sensor  representations  being  visualized,  then  the  host  platform  would  require  an  equally 
sophisticated  graphics  processing  capability.  This  was  not  the  case  for  the  work  conducted 
under  this  task  since  terrain  data  could  not  be  imported,  nor  could  any  sophisticated  sensors  be 
modelled.  The  other  aspect  that  could  place  a  high  processing  demand  is  scenario  complexity 
from  the  perspectives  of  number  of  objects  and  scenario  duration.  The  STK  hardware 
requirements  and  the  specifications  of  the  develop  platform  used  during  this  work  are  provided 
below. 


Table  4-2:  STK  Hardware  Recommended  Requirements  [25] 


Hardware 

Requirement 

CPU  Speed 

2+ GHz 

Processor 

Intel  Core  Duo,  SSE2  (or  greater)  Pentium  4  or  Xeon  Processors 

Memory  /  RAM 

3+  GB 

Disk  Space 

2+  GB 

Video  Card 

High-end  OpenGL-compatible  card  (512+  MB  memory)  that 
supports  OpenGL  2.0+. 

To  determine  whether  the  graphics  card  installed  on  your  system 
is  supported  by  STK,  from  the  Start->AII  Programs  Menu,  select 
STK  Support  Tools->Graphics  Card  Information. 

Note:  Integrated  motherboard  chipsets,  such  as  Intel  Integrated 
Graphics,  should  be  avoided. 

Network  Hardware 

Network  Card  Required 

Table  4-3:  Task  #185  Development  Platform  Specifications 


Hardware 

Specification 

CPU  Speed 

3.20  GHz 

Processor 

Intel  Core  i5-4570 

Memory  /  RAM 

8  GB  (3.43  GB  usable) 

Disk  Space 

465  GB 

Video  Card 

Intel  HD  Graphics  4600 

Network  Hardware 

Intel  Ethernet  Connection  1217-LM 

Instructions  on  how  to  install  the  free  version  of  STK  as  well  as  the  Task  185  scenario  delivered 
through  this  work  are  provided  in  Appendix  B. 
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APPENDIX  A  PLATFORM  OBJECT  ROUTE  PLANNING 

PROCEDURE 

This  appendix  contains  a  description  of  the  procedure  that  was  used  by  CAE  for  planning  and 
implementing  routes  for  Ship  and  Aircraft  Objects  within  the  STK  model. 

A  procedure  to  generate  STK  Specific  Time  routes  was  conceived,  created  and  adopted  to 
quickly  produce  large  numbers  of  recurring  routes.  Some  of  the  routes  generated  for  the  three- 
month  period  within  the  scenario  contain  between  80  and  1,500  different  waypoints.  CAE 
recommends  that  the  standard  route  generation  procedure  within  STK  tool  be  used  when 
generating  a  small  number  of  waypoints. 

The  following  procedure  is  a  record  of  what  was  done  to  generate  the  STK  Specific  Time  routes. 
CAE  does  not  imply  that  this  method  is  the  best  or  most  effective  way  to  generate  long-term 
paths  for  multiple  objects  in  STK;  however,  it  was  found  to  be  useful  for  the  work  required  by 
this  task. 

The  first  part  of  the  process  is  to  generate  a  set  of  points  on  the  map,  which  will  define  the 
desired  route  for  the  object.  Each  point  needs  to  include  latitude  and  longitude  value  measured 
in  degrees.  One  of  the  quickest  ways  of  generating  this  set  of  points  is  to  use  the  Measure 
button  in  STK’s  2D  Graphics  window  (Figure  A-1). 

The  Measure  button  can  be  used  to  measure  the  distance  between  any  two  points.  This  is  done 
by  clicking  the  Measure  button  in  the  2D  Graphics  window,  and  then  clicking  and  dragging  the 
mouse  between  the  two  points  on  the  2D  Graphics  window  you  want  to  measure.  The  latitude 
and  longitude  of  the  two  points,  the  shortest  distance  between  the  two  points  and  the  azimuth 
bearing  will  be  displayed  in  the  Status  Bar  and  the  Message  Viewer  once  the  mouse  button  is 
released. 
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Figure  A-1:  STK  Measure  Function  in  the  2D  Graphics  Window 

Repeating  this  process  across  the  desired  route  will  generate  the  necessary  set  of  points  for  the 
route  definition  in  degrees  within  the  STK  Message  Viewer. 
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Figure  A-2:  Multi-selection  of  Measure  messages  in  the  STK  Message  Viewer 


Select  all  the  distance  info  messages  by  clicking  on  the  first  message,  holding  down  the  SHIFT 
key,  and  then  select  the  last  message  (Figure  A-2).  Copy  the  selection  by  pressing  CTRL+C 
and  paste  the  distance  messages  into  a  text  editor  (Figure  A-3). 


Figure  A-3:  Pasting  the  STK  Measure  Messages  into  a  Text  Editor 

The  text  editor  can  then  be  used  to  remove  the  excess  information  so  that  only  the  latitude  and 
longitude  information  remains.  Each  point  must  be  placed  on  its  own  line  within  the  text  editor, 
where  the  latitude  and  longitude  value  are  separated  by  a  single  TAB  (Figure  A-4). 

This  can  be  completed  very  quickly  for  a  large  number  of  points  by  either  writing  an  appropriate 
script  or  using  free  open  source  software.  For  example,  the  regular  expression  option  in 
Notepad++’s  Replace  All  functionality  was  used  during  this  project  to  convert  hundreds  of  points 
into  the  desired  format  in  only  a  few  button  presses. 
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Figure  A-4:  Formatting  the  STK  Measure  Messages  into  Usable  Data  for  the  “Route 

Planning  Template”  Excel  Spreadsheet 

Once  properly  formatted,  select  the  entire  contents  of  the  text  editor  then  copy-and-paste  the 
content  into  the  Latitude  and  Longitude  columns  in  the  T rip  Planner  sheet  of  the  CAE  “Route 
Planning  Template”  Excel  spreadsheet  Figure  A-5).  Once  in  the  spreadsheet,  an  appropriate 
speed  value  should  be  added  into  the  Speed  column.  The  spreadsheet  will  then  automatically 
generate  associated  time  values  for  each  waypoint  in  the  Output  columns. 
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Figure  A-5:  Copying  the  Initial  Points  into  the  Route  Planning  Spreadsheet 
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Figure  A-6:  Adding  Speed  Values  in  the  Route  Planning  Spreadsheet 

Once  in  the  spreadsheet,  the  route  data  can  be  manipulated  in  various  ways  for  a  variety  of 
purposes.  Entire  sections  of  the  route  can  be  copied  and  pasted  to  the  bottom  of  spreadsheet 
to  have  an  object  repeat  the  selected  section  of  the  route.  The  speed  of  the  route  can  be 
randomized  by  replacing  cells  in  the  Speed  columns  with  Excel  function  in  cell  F4.  The  object 
can  be  configured  to  rest  at  a  certain  point  by  making  a  copy  of  the  point  and  changing  the 
value  in  the  Time  column  to  either  a  fixed  time  or  a  randomized  time  by  replacing  the  cell  with 
Excel  function  in  cell  14. 

The  spreadsheet  will  automatically  generate  the  equivalent  Time,  Latitude  and  Longitude  data 
for  the  STK  waypoints  in  the  Output  column.  Additional  customization  can  be  applied  by 
modifying  the  values  of  the  Altitude  column  for  Aircraft  object.  The  values  in  the  Velocity  and 
Acceleration  columns  should  remain  “0.0”  since  the  route  planner  spreadsheet  method  uses 
STK’s  Specific  Time  route  calculation  method.  Once  the  user  is  satisfied  with  the  route,  select 
and  copy  the  entire  Output  section  from  the  spreadsheet  (Figure  A-7). 
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0.0 
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1:47116 
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0.0 
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0:16:33 

1/1/1516:45 

60317. 
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0.0  0.0 
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+ 

Figure  A-7:  Copying  the  Output  Columns  from  the  Route  Planning  Spreadsheet 

Open  the  “STK  GreatArc  -  Route  Template  .  pg”  STK  Great  Arc  Propagator  file  (Figure 
A-8)  and  replace  the  "***_lnsert_Spreadsheet_columns_here_***"  line  with  the 
contents  of  the  spreadsheet.  Once  the  copy  and  paste  is  complete,  replace  the 
"***_Enter_the_number_0f_wayp0ints_here_***"  line  in  the  GreatArc  Propagator  file 
with  an  integer  value  indicating  the  number  of  waypoints  in  the  file  (Figure  A-9).  Save  the  file 
and  ensure  that  it  remains  a  STK  Great  Arc  Propagator  file  with  a  “.pg”  extension. 

Additional  information  concerning  the  STK  Great  Arc  Propagator  file  structure  can  be  found  at 
http://help.aqi.eom/stk/10.1 .3/index.html?paqe=source%2Fstk%2Fimportfiles-05.htm. 
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STK  GreatArc  -  Route  Template. pg  -  Notepad 


edeies 


File  Edit  Format  View  Help 
Stk.v. 8. 0 

begin  GreatArc 

Method  DetvelFromTime 

TimeofFirstwaypoint  1  Jan  2015  00:00:00.000 
ArcGranularity  5. 729577951308e-01 

Numberofwaypomts  *  *  ^E  nt  e  r  _t  h  e_n  um  b  e  r  _of  _way  p  o  i  nt  s  _h  e  r  e_’‘<  “  ^ 
begin  waypoints 

t,*’t'_i  nsert_spreadsheet_columns_here_v<<',‘' 
end  waypoints 
end  GreatArc 


Figure  A-8:  STK  Formatted  Great  Arc  Propagator  Route  Template  File 


LeeJLsJS 


test.pg  -  Notepad 


File  Edit  Format  View  Help 
stk.v. 8. 0 

begin  GreatArc 

Method  DetvelFromTime 

TimeofFirstwaypoint  1  Jan  2015  00:00:00.000 
ArcGranularity  5 .i^77951308e-Ql 
Number  of  waypon  nt  s|8J 


begin  waypoints 


0. 

49. 32060 

-123.31676 

0.0 

0.0 

0.0 

0.0 

3600. 

49.09185 

-123.40181 

0.0 

0.0 

0.0 

0.0 

7658. 

49. 05959 

-123.37248 

0.0 

0.0 

0.  0 

0.  0 

31584. 

48. 82496 

-123.01468 

0.0 

0.0 

0.0 

0.  0 

35546. 

48. 89828 

-123.01468 

0.0 

0.0 

0.0 

0.0 

40695. 

48. 86309 

-122. 84165 

0.  0 

0.0 

0.0 

0.  0 

41523. 

48. 85429 

-122.80939 

0.0 

0.0 

0.0 

0.0 

47176. 

49.01853 

-122.93256 

0.0 

0.0 

0.  0 

0.0 

end  waypoints 


end  GreatArc| 


Figure  A-9:  Pasting  Output  from  the  Route  Planning  Spreadsheet  into  a  STK  Formatted 


Great  Arc  Propagator  File 
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Finally,  open  the  object  properties  in  STK  and  select  the  “Import  from  File...”  button  in  the  Basic 
->  Route  page  (Figure  A-10).STK  will  accept  the  file  if  it  is  properly  formatted,  and  the  object  will 
take  on  the  route  created  in  the  spreadsheet. 


Figure  A-10:  Importing  a  STK  Great  Arc  Propagator  File  for  an  STK  Object 
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APPENDIX  B  STK  INSTALLATION  AND  CONFIGURATION 

INSTRUCTIONS 

Following  is  a  set  of  brief  instructions  describing  how  to  install  the  free  version  of  STK  10.1.3, 
the  free  additional  3D  models  and  the  delivered  Task  185  scenario. 

1.  Execute  the  STK1013OneClicklnstall  .exe  that  can  be  downloaded  from  the  AGI 
website.  The  installer  will  request  a  free  STK  license  from  AGI.  This  can  be  completed  by 
following  the  instructions  listed  by  installer.  It  will  likely  require  the  creation  of  an  account 
and  registering  with  AGI,  as  the  license  is  associated  with  the  individual  computer  on  which 
STK  is  installed. 

2.  Install  the  additional  3D  models  downloaded  from  AGI’s  3D  model  repository  to  the  STK 
installation: 

a.  Copy  and  unzip  the  contents  of  the  commuter .  zip  file  from  the  delivered  files  into  the 

C:\Program  Files  (x86) \AGI\STK  10\STKData\VO\Models\Air  folder. 

b.  Copy  and  unzip  the  contents  of  the  cruise  liner .  zip  file  from  the  delivered  files 
into  the  C : \Program  Files  (x86) \AGI\STK  10\STKData\VO\Models\Sea 

folder. 

c.  Copy  and  unzip  the  contents  of  the  opc .  zip  file  from  the  delivered  files  into  the 

C:\Program  Files  (x8 6 ) \AGI\STK  10\STKData\VO\Models\Sea  folder. 

d.  Copy  and  unzip  the  contents  of  the  rubber_boat .  zip  file  from  the  delivered  files  into 

the  C: \Program  Files  (x8 6)  \AGI\STK  10\STKData\VO\Models\Sea  folder. 

e.  Copy  and  unzip  the  contents  of  the  septar .  zip  file  from  the  delivered  files  into  the 

C:\Program  Files  (x86) \AGI\STK  10\STKData\VO\Models\Sea  folder. 

f.  Copy  and  unzip  the  contents  of  the  threat_f  reighter .  zip  file  from  the  delivered 
files  into  the  C : \Program  Files  (x86)  \AGI\STK  10\STKData\VO\Models\Sea 

folder. 

g.  Copy  and  unzip  the  contents  of  the  threat^  type_2  3_frigate.zip  file  from  the 
delivered  files  into  the  C: \Program  Files  (x86) \AGI\STK 
10\STKData\VO\Models\Sea  folder. 

3.  Install  the  delivered  scenario  onto  the  local  machine. 

a.  Copy  the  entire  CORA1 85  folder  from  the  delivered  files  to 

%USERPROFILE% \ Document s \ STK  10\  folder. 
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4.  Execute  the  STK  10  application  and  select  to  open  the  CORA  185  scenario.  Executing 
STK  and  loading  the  scenario  for  the  first  time  many  take  several  minutes.  Please  be 
patient  and  allow  the  process  to  complete. 


27  February  2015 


B-2 


5758-001  Version  01 


CAE 


DRDC  CORA  Task  #185 
Coastal  Surveillance  Baseline 
Model  Development 


APPENDIX  C  POTENTIAL  FUTURE  STK  MODEL  SPECIFICATIONS 

This  appendix  contains  a  listing  of  the  specifications  associated  with  potentially  future  desirable 
attributes  that  could  be  implemented  in  the  Pro  version  of  STK  with  custom  add-on  modules. 
The  primary  source  for  the  information  contained  within  this  appendix  was  the  STK  Help  files 
freely  accessible  online  at:  http://www.aqi.eom/resources/help/online/stk/10.1/ 

C.1  STK  Specifics  for  Potential  Follow  On  Work 

Depending  on  the  level  of  detail  that  the  user  /  analyst  wishes  to  explore  (based  on  the  activity 
requirements)  STK  is  capable  of  modelling  a  variety  of  highly  detailed  aspects  associated  with 
radar  sensors  and  communication  systems  (transmitters  and  receivers),  including  consideration 
for  certain  atmospheric  and  target  phenomena.  These  detailed  functionalities  require  licensing 
of  the  appropriate  add-on  modules  for  STK  (namely  STK  Radar  and  STK  Communications). 

If  detailed,  physics-based  interaction  analysis  amongst  sensors,  targets  and  the  environment  is 
not  necessary,  then  STK  can  accomplish  some  highly  useful  operational  planning  type 
assessments  using  the  baseline  STK  Pro  capabilities  along  with  the  STK  Coverage  module. 
The  STK  Radar  and  STK  Communications  modules  provide  the  ability  to  invoke  highly  detailed 
modelling  of  sensors  and  systems  in  those  domains. 

The  following  sections  identify  some  of  the  characteristics  and  parameters  that  can  be  included 
in  the  various  add-on  modules  depending  on  the  aims  and  objectives  of  the  users  and  analysts. 

C.1.1  Radar  Sensors 

Within  STK  Radar  there  are  a  few  different  types  of  radars  that  can  be  defined;  these  include: 

•  Monostatic; 

•  Bistatic  receiver  and  transmitter; 

•  Search  /  track  radar;  and 

•  Synthetic  aperture  radar  (SAR). 

One  can  also  define  jammers  and  detailed  antenna  models,  as  well  as  a  variety  of  effects 
associated  with  specific  types  of  atmospheric  phenomena,  such  as  rain,  gaseous  absorption, 
clouds,  fog  and  the  troposphere. 

The  basic  properties  for  a  radar  object  in  STK  include  the  following: 

•  Specifications: 

o  The  operating  frequency  or  wavelength  of  the  radar  system; 
o  The  peak  output  power  of  the  transmitter; 
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•  Radio  Frequency  Filter: 

o  When  used,  the  respective  bandwidths  are  used  to  determine  transmitter  signal  and 
receiver  bandwidths; 

•  Polarization  (select  from  types  available);  and 

•  Gains  and  Losses  (single  values  entered  by  user  in  a  list). 

The  user  can  also  define  a  variety  of  highly  details  system  specifications  (system  operating 
temperature,  receiver  noise,  transmission  line  loss  and  temperature,  antenna  noise)  to  help 
simulate  real-world  RF  situations  more  accurately  if  necessary. 

C.1.2  Radar  Cross-Section  Property 

Within  STK,  the  RF  properties  for  scenario  objects  include  a  page  for  radar  cross-section 
(RCS).  The  RCS  property  is  defined  in  association  with  one  or  more  user-specified  RF  band(s). 
The  minimum  frequency  for  the  RF  bands  is  3  MHz  while  the  maximum  is  300  GHz;  the  user 
can  insert  new  bands  and  then  must  specify  the  minimum  frequency  and  maximum  frequency 
associated  with  that  band. 

The  user  must  then  specify  which  of  four  Compute  Types  will  be  used: 

•  A  Constant  Value; 

•  An  External  File,  which  defines  an  Aspect  Dependent  RCS; 

•  A  Script  Plug-in,  which  computes  aspect  dependent  RCS  values  for  each  time  step  in  a 
radar  computation  based  on  a  set  of  Input  Arguments  including  Frequency,  Incident  Angles 
and  Vectors,  Reflected  Angles  and  Vectors;  and 

•  A  RCS  COM  Plug-in,  if  available  and  properly  registered  in  the  local  machine. 

The  user  must  then  select  one  of  five  Swerling  cases  to  account  for  RCS  fluctuations.  These 
cases  are  situation  and  case  dependent  and  must  be  reviewed  by  the  user  /  analyst  in  the  STK 
Help  documentation. 

C.1.3  Radar  Plugin  Points 

STK  Radar  also  provides  plugin  points  for  the  following  aspects: 

•  Custom  antenna  gain; 

•  Absorption  loss  model; 

•  Rain  loss  model; 

•  Custom  loss  model; 
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•  Filter; 

•  Search  /  track  constraint; 

•  SAR  constraint;  and 

•  Radar  cross  section. 

C.1.4  Communication  Systems 

STK  Communications  is  required  to  define  transmitter  and  receiver  objects. 

Transmitters 

A  Transmitter  object  in  STK  models  the  characteristics  of  the  transmitter,  the  antenna  it  uses 
and  the  environment  in  which  it  operates.  The  basic  properties  of  a  Simple  Transmitter  object 
are: 

•  Carrier  frequency; 

•  Effective  Isotropic  Radiated  Power; 

•  Data  rate  (in  bits  per  second); 

•  Polarization  (selectable); 

•  Modulator  type  (selectable  or  user-defined); 

•  Filter  (selectable);  and 

•  Additional  gains  and  losses. 

NOTE  that  in  addition  to  Simple  Transmitters  there  are  seven  other  types  of  transmitters  that 
can  be  implemented: 

•  Cable; 

•  Medium; 

•  Complex; 

•  Multi-beam; 

•  Plug-in; 

•  Laser;  and 
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•  GPS  satellite. 

The  characteristics  of  frequency,  power,  data  rate,  polarization  and  filters  tend  to  be  common 
among  most  of  the  transmitter  types,  although  there  are  some  specific  aspects  for  the  different 
types  depending  on  the  required  level  of  detail. 

Receivers 

A  Receiver  object  in  STK  models  the  characteristics  of  the  receiver,  the  antenna  it  uses  and  the 
environment  in  which  it  operates.  The  basic  properties  of  a  Simple  Receiver  object  are: 

•  Frequency  (desired  value  or  Auto  T rack  option); 

•  System  gain  divided  by  system  temperature; 

•  Polarization; 

•  Rain  model  (selectable); 

•  Demodulator  type  (selectable  or  user-defined); 

•  Filter  (selectable);  and 

•  Additional  gains  and  losses. 

NOTE  that  in  addition  to  Simple  Receivers  there  are  seven  other  types  of  transmitters  that  can 
be  implemented: 

•  Cable; 

•  Medium; 

•  Complex; 

•  Multi-beam; 

•  Laser; 

•  Plug-in  Laser;  and 

•  Plug-in  RF. 

C.1.5  Communications  Plugin  Points 

STK  Radar  also  provides  plugin  points  to  allow  users  /  developers  to  specify  their  own  custom 
models.  Plugin  points  are  available  for  the  following  aspects: 
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•  Transmitter  model; 

•  Receiver  model; 

•  Custom  antenna  gain; 

•  Absorption  loss  model; 

•  Rain  loss  model; 

•  Custom  loss  model; 

•  Antenna  multi-beam  selection  strategy; 

•  Communication  system  link  selection  strategy; 

•  Modulator; 

•  Demodulator; 

•  Filter;  and 

•  Communication  constraint. 

C.1.6  STK  Coverage 

As  identified  in  the  STK  Help  files,  the  STK  Coverage  module  allows  the  user  to  “analyze  the 
global  or  regional  coverage  provided  by  one  or  more  assets  while  considering  all  access 
constraints.”  To  facilitate  this  type  of  analysis,  the  STK  Coverage  module  provides  two 
additional  object  classes:  Coverage  Definition,  and  Figure  of  Merit. 

The  Coverage  Definition  object  allows  the  user  to  define  and  specify: 

•  The  coverage  area  and  an  associated  grid  point  spacing  (resolution)  over  the  area; 

•  The  STK  objects  providing  the  coverage;  and 

•  The  time  period  of  interest. 

The  results  of  a  coverage  analysis  can  be  displayed  in  both  the  2D  and  3D  Graphics  Windows, 
as  well  as  in  the  form  of  a  text-based  coverage  report.  Table  C-1  identifies  the  types  of 
coverage  reports  and  graphs  as  well  as  figures  of  merit  available  through  STK  Coverage  as 
listed  in  the  STK  Help  files: 
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Table  C-1:  Coverage  Reports  and  Graphs 


Coverage  Reports  and  Graphs 

Region  Coverage 

Access  Duration 

Region  Full  Coverage 

Coverage  by  Asset 

Region  Pass  Coverage 

Gap  Duration 

Point  Coverage 

Gaps  in  Global  Coverage 

Point  Daily  Coverage 

Global  Coverage 

Point  Probability  of  Coverage 

Percent  Coverage 

Coverage  by  Latitude 

Time  to  Cover  by  Region 

Figures  of  Merit 

Measuring  Simple  Coverage 

Number  of  Accesses 

Number  of  Assets 

Access  Separation 

Coverage  Time 

Number  of  Gaps 

Revisit  Time 

Average  Length  of  Coverage  Gap 

Access  Duration 

Response  Time 

C.1.7  STKEOIR 

The  STK  Help  files  identify  a  STK  EOIR  (Electro  Optical  Infrared)  module;  however,  it 
specifically  indicates  that  the  capability,  which  was  developed  by  the  Space  Dynamics 
Laboratory  (SDL),  models  “detection,  tracking,  and  imaging  performance  of  electro-optical  and 
infrared  sensors  for  earth  science,  missile  defense,  and  space  situational  awareness 
applications.”  The  Canadian  representative  for  AGI  was  asked  if  STK  had  the  capability  to 
perform  EOIR  sensor  modelling  in  the  maritime  coastal  surveillance  context  and  no  specific 
answer  was  provided. 
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APPENDIX  D  SAMPLE  ACCESS  CALCULATIONS 

The  first  set  of  Access  calculations  are  for  the  CPI 40  aircraft  object  against  the  two  outer  MARPAC  Area  Target  objects.  For  these 
calculations,  the  Constraints  (azimuth,  elevation  and  range)  that  were  assigned  to  the  CPI 40  object  are  taken  into  account.  Figure 
D-1  depicts  the  Access  calculation  set-up. 


Figure  D-1:  CPI  40  Access  Setup 
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D.1  CPI 40  Aircraft  with  Basic  Constraints  -  to  -  MARPAC  Outer  North 


28  Jan  2015  18:51:41 

Aircraf t-CP140  Aurora-To-AreaTarget-MARPAC  Outer  North:  Access  Summary  Report 
CP140  Aurora-To-MARPAC  Outer  North 


Access  Start  Time  (UTCG) 


Stop  Time  (UTCG) 


Duration  (sec) 


Global  Statistics 


Min  Duration 
Max  Duration 


1 

5 

Jan 

2015 

00:19:32.665 

5 

Jan 

2015 

02:28:25.453 

7732.788 

2 

9 

Jan 

2015 

11:28:27.261 

9 

Jan 

2015 

14:47:53.673 

11966.412 

3 

14 

Jan 

2015 

06:31:51.665 

14 

Jan 

2015 

08:40:44.784 

7733.119 

4 

17 

Jan 

2015 

02:40:47.247 

17 

Jan 

2015 

06:00:12.673 

11965.426 

5 

21 

Jan 

2015 

18:44:10.665 

21 

Jan 

2015 

20:53:03.784 

7733.119 

6 

25 

Jan 

2015 

19:53:06.261 

25 

Jan 

2015 

23:12:32.673 

11966.412 

7 

30 

Jan 

2015 

14:56:29.665 

30 

Jan 

2015 

17:05:22.784 

7733.119 

8 

3 

Feb 

2015 

16:05:25.261 

3 

Feb 

2015 

19:24:51.673 

11966.412 

9 

7 

Feb 

2015 

02:08:48.698 

7 

Feb 

2015 

04:17:41.784 

7733.086 

10 

11 

Feb 

2015 

02:17:44.261 

11 

Feb 

2015 

05:37:10.673 

11966.412 

11 

14 

Feb 

2015 

17:21:08.665 

14 

Feb 

2015 

19:30:01.453 

7732.788 

12 

19 

Feb 

2015 

07:30:03.261 

19 

Feb 

2015 

10:49:29.673 

11966.412 

13 

24 

Feb 

2015 

08:33:27.665 

24 

Feb 

2015 

10:42:20.784 

7733.119 

14 

28 

Feb 

2015 

21:42:23.247 

1 

Mar 

2015 

01:01:48.673 

11965.426 

15 

5 

Mar 

2015 

15:45:46.665 

5 

Mar 

2015 

17:54:39.784 

7733.119 

16 

8 

Mar 

2015 

08:54:42.261 

8 

Mar 

2015 

12:14:08.673 

11966.412 

17 

11 

Mar 

2015 

06:58:05.665 

11 

Mar 

2015 

09:06:58.784 

7733.119 

18 

16 

Mar 

2015 

00:07:01.261 

16 

Mar 

2015 

03:26:27.673 

11966.412 

19 

19 

Mar 

2015 

00:10:24. 698 

19 

Mar 

2015 

02:19:17.784 

7733.086 

20 

23 

Mar 

2015 

22:19:20.261 

24 

Mar 

2015 

01:38:46.673 

11966.412 

21 

26 

Mar 

2015 

16:22:44.665 

26 

Mar 

2015 

18:31:37.453 

7732.788 

22 

30 

Mar 

2015 

09:31:39.261 

30 

Mar 

2015 

12:51:05.673 

11966.412 

23 

3 

Apr 

2015 

23:35:03.665 

4 

Apr 

2015 

01:43:56.784 

7733.119 

24 

8 

Apr 

2015 

09:43:59.247 

8 

Apr 

2015 

13:03:24.673 

11965.426 

11 

14 

Feb 

2015 

17:21:08.665 

14 

Feb 

2015 

19:30:01.453 

7732.788 

6 

25 

Jan 

2015 

19:53:06.261 

25 

Jan 

2015 

23:12:32.673 

11966.412 
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Mean  Duration  9849.598 

Total  Duration  236390.353 


Aircraft-CP140_Aurora-To-AreaTarget-MARPAC_Outer_North:  Access  Times  -  28  Jan  201 5  18:54:04 


Times  (UTCG) 

Figure  D-2:  Sample  CP140  Access  to  Outer  North  AOR  Results 
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D.2  CPI 40  Aircraft  with  Basic  Constraints  -  to  -  MARPAC  Outer  South 

28  Jan  2015  18:56:05 

Aircraf t-CP140_Aurora-To-AreaTarget-MARPAC_Outer  South:  Access  Summary  Report 
CP140  Aurora-To-MARPAC  Outer  South 


Access  Start  Time  (UTCG)  Stop  Time  (UTCG)  Duration  (sec) 


1 

5 

Jan 

2015 

01:24:04.318 

5 

Jan 

2015 

02:53:41.222 

5376.904 

2 

5 

Jan 

2015 

06:05:05.876 

5 

Jan 

2015 

06:31:18.169 

1572.293 

3 

9 

Jan 

2015 

11:03:40.073 

9 

Jan 

2015 

12:20:26.479 

4606.405 

4 

9 

Jan 

2015 

13:48:01.228 

9 

Jan 

2015 

18:04:46.876 

15405.647 

5 

14 

Jan 

2015 

07:36:23.701 

14 

Jan 

2015 

09:06:00.222 

5376.521 

6 

14 

Jan 

2015 

12:17:24.876 

14 

Jan 

2015 

12:43:37.308 

1572.432 

7 

17 

Jan 

2015 

02:15:59.818 

17 

Jan 

2015 

03:32:46.479 

4606.660 

8 

17 

Jan 

2015 

05:00:20.228 

17 

Jan 

2015 

09:17:05.876 

15405.647 

9 

21 

Jan 

2015 

19:48:43.318 

21 

Jan 

2015 

21:18:19.222 

5375.904 

10 

22 

Jan 

2015 

00:29:43.876 

22 

Jan 

2015 

00:55:56.308 

1572.432 

11 

25 

Jan 

2015 

19:28:19.073 

25 

Jan 

2015 

20:45:05.479 

4606.405 

12 

25 

Jan 

2015 

22:12:39.731 

26 

Jan 

2015 

02:29:24.889 

15405.158 

13 

30 

Jan 

2015 

16:01:02.318 

30 

Jan 

2015 

17:30:38.433 

5376.114 

14 

30 

Jan 

2015 

20:42:02.876 

30 

Jan 

2015 

21:08:15.308 

1572.432 

15 

3 

Feb 

2015 

15:40:38.073 

3 

Feb 

2015 

16:57:24.479 

4606.405 

16 

3 

Feb 

2015 

18:24:58.731 

3 

Feb 

2015 

22:41:43.889 

15405.158 

17 

7 

Feb 

2015 

03:13:21.318 

7 

Feb 

2015 

04:42:57.433 

5376.114 

18 

7 

Feb 

2015 

07:54:22.035 

7 

Feb 

2015 

08:20:34.308 

1572.273 

19 

11 

Feb 

2015 

01:52:57.073 

11 

Feb 

2015 

03:09:43.479 

4606.405 

20 

11 

Feb 

2015 

04:37:17.731 

11 

Feb 

2015 

08:54:03.876 

15406.144 

21 

14 

Feb 

2015 

18:25:40.318 

14 

Feb 

2015 

19:55:17.222 

5376.904 

22 

14 

Feb 

2015 

23:06:41.876 

14 

Feb 

2015 

23:32:54.169 

1572.293 

23 

19 

Feb 

2015 

07:05:16.073 

19 

Feb 

2015 

08:22:02.479 

4606.405 

24 

19 

Feb 

2015 

09:49:37.228 

19 

Feb 

2015 

14:06:22.876 

15405.647 

25 

24 

Feb 

2015 

09:37:59.701 

24 

Feb 

2015 

11:07:36.222 

5376.521 

26 

24 

Feb 

2015 

14:19:00.876 

24 

Feb 

2015 

14:45:13.308 

1572.432 

27 

28 

Feb 

2015 

21:17:35.818 

28 

Feb 

2015 

22:34:22.479 

4606.660 

28 

1 

Mar 

2015 

00:01:56.228 

1 

Mar 

2015 

04:18:41.876 

15405.647 

29 

5 

Mar 

2015 

16:50:19.318 

5 

Mar 

2015 

18:19:55.222 

5375.904 
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Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


30 

5 

Mar 

2015 

21:31:19.876 

31 

8 

Mar 

2015 

08:29:55.073 

32 

8 

Mar 

2015 

11:14:15.731 

33 

11 

Mar 

2015 

08:02:38.318 

34 

11 

Mar 

2015 

12:43:38.876 

35 

15 

Mar 

2015 

23:42:14.073 

36 

16 

Mar 

2015 

02:26:34.731 

37 

19 

Mar 

2015 

01:14:57.318 

38 

19 

Mar 

2015 

05:55:58.035 

39 

23 

Mar 

2015 

21:54:33.073 

40 

24 

Mar 

2015 

00:38:53.731 

41 

26 

Mar 

2015 

17:27:16.318 

42 

26 

Mar 

2015 

22:08:17.876 

43 

30 

Mar 

2015 

09:06:52.073 

44 

30 

Mar 

2015 

11:51:13.228 

45 

4 

Apr 

2015 

00:39:35.701 

46 

4 

Apr 

2015 

05:20:36.876 

47 

8 

Apr 

2015 

09:19:11.818 

48 

8 

Apr 

2015 

12:03:32.228 

38 

19 

Mar 

2015 

05:55:58.035 

20 

11 

Feb 

2015 

04:37:17.731 
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5 

Mar 

2015 

21:57:32 

8 

Mar 

2015 

09:46:41 

8 

Mar 

2015 

15:31:00 

11 

Mar 

2015 

09:32:14 

11 

Mar 

2015 

13:09:51 

16 

Mar 

2015 

00:59:00 

16 

Mar 

2015 

06:43:19 

19 

Mar 

2015 

02:44:33 

19 

Mar 

2015 

06:22:10 

23 

Mar 

2015 

23:11:19 

24 

Mar 

2015 

04:55:38 

26 

Mar 

2015 

18:56:53 

26 

Mar 

2015 

22:34:30 

30 

Mar 

2015 

10:23:38 

30 

Mar 

2015 

16:07:58 

4 

Apr 

2015 

02:09:12 

4 

Apr 

2015 

05:46:49 

8 

Apr 

2015 

10:35:58 

8 

Apr 

2015 

16:20:17 

19 

Mar 

2015 

06:22:10 

11 

Feb 

2015 

08:54:03 

1572.432 

4606.405 

15405.158 

5376.114 

1572.432 

4606.405 

15405.158 

5376.114 

1572.273 

4606.405 

15405.158 

5376.904 

1572.293 

4606.405 

15405.647 

5376.521 

1572.432 

4606.660 

15405.647 


1572.273 

15406.144 

6740.176 

323528.432 


308 

479 

889 

433 

308 

479 

889 

433 

308 

479 

889 

222 

169 

479 

876 

222 

308 

479 

876 

308 

876 
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2015 


Aircraft-CP140_Aurora-To-AreaTarget-MARPAC_Outer_South:  Access  Times  -28  Jan  2015  18:56:51 


Times  (UTCG) 

Figure  D-3:  Sample  CP140  Access  to  Outer  South  AOR  Results 
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The  next  example  is  based  on  CP140  Access  calculations  against  the  two  Outer  and  two  Inner  MARPAC  areas  for  the  duration  of 
the  scenario  time  period.  The  pie  chart  (Figure  D-4)  depicts  Cumulative  Dwell  of  the  four  areas  combined  throughout  the  scenario 
period.  The  result  is  that,  based  on  the  flight  paths,  mission  times,  Access  Constraints  and  MARPAC  area  definitions,  the  CP140 
can  observe  at  least  some  part  of  the  four  areas  for  7.7%  of  the  full  three  month  period. 


I  I  Cumulative  Dwell  647029  03(sec)  =  7  7% 

I  I  Cumulative  Gap  7796640  97isect  =  92  3% 


Cumulative  Dwell  -  28  Jan  2015  19:04:58  ■  28  Jan  2015  19:06:37 

7.663% 

^  - 


92.337% 


Figure  D-4:  Sample  CPI  40  Cumulative  Dwell  Access  Results 
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D.3  MARPAC  Full  Area  -  to  -  Satellite  Objects 

This  next  set  of  Access  calculations  are  for  a  group  of  space-based  assets  (satellites)  against  the  full  MARPAC  area 
(MARPAC_Full).  For  this  calculation,  the  Access  computations  are  done  from  the  perspective  of  the  Area  Target  object  -  that  is,  the 
calculation  looks  for  times  when  any  part  of  the  MARPAC_Full  area  is  in  direct  line  of  sight  of  any  of  the  satellites.  Because  the 
satellites  are  present  throughout  the  scenario  period  and  their  orbital  periods  are  relatively  short  in  duration,  Access  calculations  for 
this  set-up  produce  a  large  quantity  of  results.  Therefore,  the  calculation  period  has  been  reduced  to  the  first  two  weeks  of  the  full 
time  period.  Even  for  this  shortened  period,  the  text  report  is  far  too  lengthy  to  include  in  this  document;  only  the  graphical  outputs 
are  presented. 

The  first  graphic  (Figure  D-5)  is  the  basic  Access  from  the  MARPAC_Full  area  to  each  of  the  satellites. 
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Access  Times  -  28  Jan  2015  19:21:56 


MARPAC_Fu!l-To-Aprizesat3_35686  -  Times  (UTCG)  MARPAC_Full-To-Aprizesat6_37793  -  Times  (UTCG)  MARPAC_Full-To-exactview1_38709  -  Times  (UTCG) 

MARPAC_Full-To-Goe5l3_29155  -  Times  (UTCG)  MARPAC_Full-To-Goes15_36411  -  Times  (UTCG)  MARPAC_Full-To-lss_25544  -  Times  (UTCG) 

MARPAC_Full-To-Radarsat2_32382  -  Times  (UTCG)  MARPAC_Full-To-Resourcesat1_28051  -  Times  (UTCG)  MARPAC_Full-To-Vesselsat1_37840  -  Times  (UTCG) 

MARPAC_Full-T o-Vesselsat2_38047  -  Times  (UTCG) 

Figure  D-5:  Sample  Satellite  Access  to  MARPAC  AOR 

One  can  see  that  the  GOES  satellites  are  always  within  view  of  the  area  because  they  are  in  a  geosynchronous  orbit  over  the 
western  hemisphere. 

For  the  second  graphic  (Figure  D-6)  the  GOES  satellites  have  been  excluded  from  the  calculation  to  achieve  aims  of  the 
demonstration.  The  graphic  shows  the  Cumulative  Dwell  calculation  -  that  is,  the  cumulative  amount  of  time  that  any  part  of  the 
MARPAC_Full  area  is  in  line  of  sight  of  any  of  the  satellites  (excluding  GOES  assets),  as  a  percentage  of  the  two  week  analysis 
period.  The  result  can  be  interpreted  as  follows:  the  group  of  satellites  operating  as  a  collective  resource  have  line  of  sight  access  to 
at  least  a  single  spot  within  the  MARPAC_FULL  area  for  57.3%  of  the  full  two  week  period. 


27  February  2015 


D-9 


5758-001  Version  01 


CAE 


DRDC  CORA  Task  #185 
Coastal  Surveillance  Baseline 
Model  Development 


Cumulative  Dwell-  28  Jan  2015  19:31:37 


I  I  Cumulative  Dwell  692991  97(sec)  ■  57  3% 
I  I  Cumulative  Gap  516607  03< sec)  ■  42.7% 


Figure  D-6:  Sample  Satellite  Cumulative  Dwell 
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D.4  CP140  Aircraft  with  Basic  Constraints  -  to  -  Cargo  Vessels  #1  through  #10 

This  set  of  calculations  was  done  for  the  CPI 40  Aircraft  Object  against  the  first  10  Cargo  Vessels.  The  time  period  used  was  the  first 
two  weeks  of  the  scenario  to  keep  the  result  output  size  reasonable  for  reporting.  Following  are  the  text  and  graphic  results  (Figure 
D-7). 

Aircraf t-CPl40_Aurora-To-Ship-Cargo_Vessel_l ,  Ship-Cargo_Vessel_10 ,  Ship-Cargo_Vessel_2 ,  Ship- 
Cargo_Vessel_3 ,  Ship-Cargo_Vessel_4 ,  Ship-Cargo_Vessel_5 ,  Ship-Cargo_Vessel_6 ,  Ship-Cargo_Vessel_7 ,  Ship- 
Cargo_Vessel_8 ,  Ship-Cargo_Vessel_9 :  Access  Summary  Report 


CP140_Aurora-To-Cargo_Vessel_l 


Access  Start  Time  (UTCG) 


Stop  Time  (UTCG) 


Duration  (sec) 


1  4  Jan  2015  22 

2  5  Jan  2015  03 


43:35.931  4  Jan 
48:07.570  5  Jan 


2015  23:13:37.734 
2015  04:19:55.061 


1801.803 

1907.491 


Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


1  4  Jan  2015  22 

2  5  Jan  2015  03 


43:35.931  4  Jan 
48:07.570  5  Jan 


2015  23:13:37.734 
2015  04:19:55.061 


1801.803 
1907.491 
1854 . 647 
3709.294 


CP140_Aurora-To-Cargo_Vessel_10 


Access  Start  Time  (UTCG) 


Stop  Time  (UTCG) 


Duration  (sec) 


1  5  Jan  2015  07:26:04.337 

2  9  Jan  2015  18:56:07.817 


5  Jan  2015  07:44:04.212 
9  Jan  2015  19:08:30.190 


1079.875 

742.373 


Global  Statistics 


Min  Duration 


9  Jan  2015  18:56:07.817 


9  Jan  2015  19:08:30.190 


742.373 
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Max  Duration  1  5  Jan  2015  07:26:04.337 

Mean  Duration 
Total  Duration 


CP140_Aurora-To-Cargo_Vessel_2 


Access  Start  Time  (UTCG) 


Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


1  5  Jan  2015  07:40:18.578 

2  9  Jan  2015  18:49:03.480 


1  5  Jan  2015  07:40:18.578 

2  9  Jan  2015  18:49:03.480 


CP140_Aurora-To-Cargo_Vessel_3 


No  Access  Found 


CP140_Aurora-To-Cargo_Vessel_4 


No  Access  Found 


CP140_Aurora-To-Cargo_Vessel_5 


Access  Start  Time  (UTCG) 


1  4  Jan  2015  22:44:53.704 

2  5  Jan  2015  03:46:34.478 

3  9  Jan  2015  10:12:56.835 
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5  Jan  2015  07:44:04.212 


1079.875 
911 . 124 
1822.248 


Stop  Time  (UTCG)  Duration  (sec) 


5  Jan  2015  07:41:04.995  46.417 

9  Jan  2015  19:07:28.998  1105.517 


5  Jan  2015  07:41:04.995  46.417 

9  Jan  2015  19:07:28.998  1105.517 

575.967 

1151.934 


Stop  Time  (UTCG) 


Duration  (sec) 


4  Jan  2015  23:16:03.089 

5  Jan  2015  04:19:06.498 
9  Jan  2015  10:23:33.511 


1869.385 

1952.020 

636.676 
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Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


4  9  Jan  2015  18:23:59.116 

5  9  Jan  2015  19:07:29.000 


5  9  Jan  2015  19:07:29.000 
2  5  Jan  2015  03:46:34.478 


CP140_Aurora-To-Cargo_Vessel_6 


Access  Start  Time  (UTCG) 


Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


1  5  Jan  2015  07:21:20.592 

2  9  Jan  2015  18:51:05.778 


2  9  Jan  2015  18:51:05.778 
1  5  Jan  2015  07:21:20.592 


CP140_Aurora-To-Cargo_Vessel_7 


No  Access  Found 


CP140_Aurora-To-Cargo_Vessel_8 


Access  Start  Time  (UTCG) 


1  5  Jan  2015  07:26:04.337 


27  February  2015 


D-13 


DRDC  CORA  Task  #185 
Coastal  Surveillance  Baseline 
Model  Development 


9  Jan  2015  18:55:11.451  1872.335 

9  Jan  2015  19:09:49.698  140.698 


9  Jan  2015  19:09:49.698  140.698 

5  Jan  2015  04:19:06.498  1952.020 

1294.223 
6471 . 114 


Stop  Time  (UTCG)  Duration  (sec) 


5  Jan  2015  07:41:04.997  1184.405 

9  Jan  2015  19:10:28.209  1162.431 


9  Jan  2015  19:10:28.209  1162.431 

5  Jan  2015  07:41:04.997  1184.405 

1173.418 

2346.836 


Stop  Time  (UTCG) 


Duration  (sec) 


5  Jan  2015  07:44:04.209  1079.871 
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Global  Statistics 


Min  Duration  1  5  Jan  2015  07:26:04.337 

Max  Duration  1  5  Jan  2015  07:26:04.337 

Mean  Duration 
Total  Duration 


CP140_Aurora-To-Cargo_Vessel_9 


Access  Start  Time  (UTCG) 


Global  Statistics 


Min  Duration 
Max  Duration 
Mean  Duration 
Total  Duration 


5  Jan  2015  07:40:18.578 


1 

1 


5  Jan  2015  07:40:18.578 
5  Jan  2015  07:40:18.578 


27  February  2015 


D-14 


DRDC  CORA  Task  #185 
Coastal  Surveillance  Baseline 
Model  Development 


5  Jan  2015  07:44:04.209  1079.871 

5  Jan  2015  07:44:04.209  1079.871 

1079.871 

1079.871 


Stop  Time  (UTCG)  Duration  (sec) 


5  Jan  2015  07:41:04.995 


46.417 


5  Jan  2015  07:41:04.995  46.417 

5  Jan  2015  07:41:04.995  46.417 

46.417 

46.417 
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CPI  40_Aurora-T  o-Cargo_Vessel_9 


CPI  40_Aurora-T  o-Cargo_Vessel_8 


CPI  40_Aurora-T  o-Cargo_Vessel_6 


CPI  40_Aurora-T  o-Cargo_Vessel_5 


CPI  40_Aurora-T  o-Cargo_Vessel_2 


CP140_Aurora-T  o-Cargo_Vessel_10 


CPI  40_Aurora-T  o-Cargo_Vessel_1 
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Access  Times  -  29  Jan  2015  10:20:32 


CP140_Aurora-To-Cargo_Vessel_1  -  Times  (UTCG)  CP140_Aurora-To-Cargo_Vessel_10  -  Times  (UTCG)  CP140_Aurora-To-Cargo_Vessel_2  -  Times  (UTCG) 

CP140_Aurora-To-Cargo_Vessel_5  -  Times  (UTCG)  CP140_Aurora-To-Cargo_Vessel_6  -  Times  (UTCG)  CP140_Aurora-To-Cargo_Vessel_8  -  Times  (UTCG) 

CP140_Aurora-To-Cargo_Vessel_9  -  Times  (UTCG) 

Figure  D-7:  Sample  CPI 40  Access  with  Basic  Constraints 
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APPENDIX  E  ACRONYMS  AND  ABBREVIATIONS 


Acronym 

Definition 

AGI 

Analytical  Graphics  Inc. 

AIS 

Automatic  Information  System 

AOR 

Area  of  Responsibility 

CFB 

Canadian  Forces  Base 

CORA 

Centre  for  Operational  Research  and  Analysis 

DEM 

Digital  Elevation  Maps 

DRDC 

Defence  Research  and  Development  Canada 

DTED 

Digital  Terrain  Elevation  Data 

EO 

Electro-Optic 

GPS 

Global  Positioning  System 

GT 

Gross  Tonnage 

IR 

Infrared 

ISR 

Intelligence  Surveillance  and  Reconnaissance 

MARPAC 

Maritime  Command  Pacific 

RCN 

Royal  Canadian  Navy 

RCS 

Radar  Cross  Section 

RF 

Radio  Frequency 

RS2 

RadarSat2 

SAR 

Synthetic  Aperture  Radar 

SDL 

Space  Dynamics  Library 

SOW 

Statement  of  Work 

SSC 

Space  Surveillance  Catalogue 

STK 

System  Toolkit 

TA 

Technical  Authority 
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